[GSoC] Simple Media Center Components
Hi, My name's Adam Jordanek and I want to working for plasma this year. My irc nick: dotevo. My proposal is here http://docs.google.com/Doc?id=dccnz6qc_47cxgwxvcc , and here http://socghop.appspot.com/student_proposal/show/google/gsoc2009/dotevo/t123840788729 I want to know your opinions about my proposal. If I did mistake, please correct me. Regards, Adam Jordanek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [GSoC] (One more) Proposal for Plasmate
Please, if you have any ideas for the git timeline or for the previewer, don't be shy to share it with us =D The simplest previewer would probably be using plasmoidviewer, with temporary installs. So you'd have a 'preview' button of sorts. The user would write code, click the button (or use a hotkey), and we'd do a temporary install and display with plasmoidviewer. This is already in line with what normal IDE's do :P I have no idea at the moment how much more powerful than this can we make the previewer (I don't think pseudo-realtime is easy nor useful enough to justify the effort), and am right now inclined to think that a basic one (like the one above) would work quite well :) About the git timeline I don't personally think it needs to be a very elaborate widget (or in fact even a widget that looks like a timeline). It could just be something list-like that readily reflects order and looks kinda pretty, with points that are readily selectable and that, say, shows information on mouse-over. I think the diff information idea is great though, and shouldn't be too hard to do :P So I was thinking of having a separate interface dedicated to save point browsing, where users can select save points from a list/timeline interface to browse the project files as they were at that save point, with diff-like colour indicators in place. I have incorporated these thoughts (together with some ugly UI mockups :P) into my proposal draft. Please take a look and give me some feedback if you have the time :) The draft is here : http://docs.google.com/Doc?id=dvjmcm4_16hjv6txcf Thanks a lot! Lim Yuen Hoe http://yuenhoe.co.cc/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC Educational Layout Proposal
A Tuesday 31 March 2009 03:17:43, Artur Souza (MoRpHeUz) escreveu: Hi! 2009/3/30 Ana Cecília Martins Barbosa anacecili...@gmail.com: Here is the link: http://docs.google.com/Doc?id=ddxppm45_14qmm45zcs Just read and really liked the idea and pinheiro's mockups. It's a killing feature for plasma reaching even more different users. I can't say much about the implementation details but it looks good to use already available technologies like Avahi and Bonjour protocol. Probably Jolie will help this (help from fabrizio ? =P) and Rob's proposal also fits nice with this!! =) Cheers! yeap there are plenty of pieces out there than can help in geting this done and more like for example the, wen i get nera the math calss room i get a notification to log in to the math class, that outomatcly chages your plasma layout checks the regestry book for that class and synks your homeworks for that class. possibilities are endless and wen you realy think about it you think its realy stypid no one as done this before -- Oxygen coordinator ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Support for transparent panel without composition
On 2009-03-30 17:32:34, Aaron Seigo wrote: so .. on a purely technical level .. the invokeMethod is really ugly (though probably mildly less ugly than stuffing the API in libplasma), and will of course not work with other Containment::PanelContainment type Containments unless they duplicate the code. and there's really no way of not duplicating the code in each PanelContainment to guarantee perfect results. for wallpapers that animate (e.g. the slideshow) this would cause full panel repaints during animation, over and over, with the rather more expensive SourceUnder compositing. this would likely destroy performance both for the animation and the rest of plasma on machines that already are struggling to provide service w/out compositing and/or OpenGL available to them. grabWidget causes a full repaint, which would be even more expensive (so we're talking about a paint on the desktop causing a repaint in the panel and another repaint in the desktop); grabWindow would just grab the relevant bits but likely has its own problems? there's also future proofing concerns there with multiple overlapping panels and per-desktop panels. i hope this all helps to explain why it's simply not an option. David Nolden wrote: - I know invokeMethod is ugly, that's why there was the public interface before.. - About the updating: Yes of course, but isn't it the same with plasmoids? - The gab(..) calls are restricted to the area under the panel, which usually only contains a part of the wallpaper, so we're mainly talking about blitting here Actually, I don't need this feature in this incarnation, and would consider allowing to setting a configurable rendering background for transparent panels, extenders, etc. much more useful, since it would solve the problem not only for the panels. If the user would set the background to the same as the wallpaper, he would have a transparency-like effect without a hack. That sounds like a very sensible approach: nicer looking translucent themes without one hell of a hack. I'd say go for it! - Rob --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/472/#review746 --- On 2009-03-30 06:37:48, David Nolden wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/472/ --- (Updated 2009-03-30 06:37:48) Review request for Plasma. Summary --- Many people can not, or do not want to use composition. A semi-transparent panel highly increases the appeal of a Desktop, and there currently is only very few plasma themes available that have a nice-looking panel without transparency enabled. All other major linux Desktop-Environments support transparent panels without composition(KDE 3.x, GNOME, and others), and since usually the only thing that needs to be visible through the panel is the Desktop itself, using a composition-less approach does not have much disadvantage here. Here's I'm proposing a patch to achieve this in a relatively clean way: The panel is painted and updated as if it was a plasmoid on the Desktop itself, grabbing the painted area plasma-internally directly from the underlying desktop-view. The corresponding area of the panel is updated whenever the desktop is repainted, which means that animated plasmoids partially hidden under the panel, animations like the desktop-fading, moving plasmoids partially under the panel, etc. just work. Result: A nice looking panel for everyone, less work for theme designers. Please don't leave those behind who don't want or can not use desktop composition! (Note: If you try this out, it doesn't work with all themes, since some themes seem to have no alpha-information in the non-composition case). Diffs - trunk/KDE/kdebase/workspace/plasma/containments/panel/panel.h 940781 trunk/KDE/kdebase/workspace/plasma/containments/panel/panel.cpp 940781 trunk/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.h 940781 trunk/KDE/kdebase/workspace/plasma/shells/desktop/desktopview.cpp 940781 trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.h 940781 trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.cpp 940781 trunk/KDE/kdebase/workspace/plasma/shells/desktop/plasmaapp.h 940781 trunk/KDE/kdebase/workspace/plasma/shells/desktop/plasmaapp.cpp 940781 Diff: http://reviewboard.kde.org/r/472/diff Testing --- Thanks, David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Signals and slots for containment show and hide actions (mainly for panels)
- in my Run Command plasmoid that uses KHistoryComboBox to make it work in panels (I've created report about problems with them and others on GraphicsView); this is working around a problem in QGraphicsScene/View, really; it will get fixed (it's being worked on) so there's no reason to hack around it today. there may even be other ways to do it nicely with the combo being manually shown as the popup for the applet, which would also keep the panel from hiding. They are working on this bug? Finally, thanks for information. :-) But I hoped that this will be fixed for Qt 4.5... I'm not sure if Qt 4.6 will be released in this year, so it could be possible that users (including myself ;-)) would need to wait probably for KDE 4.5 in mid 2010. But what can I do now with this? I was already thinking about own list emulating that from combo, but there is still problem with not working context menu and no way to get focus on field when in panel (or probably when there are windows on the desktop). I was thinking also about turning combobox into lineedit for panels but then it would be less usable and there are still chances that context menu would not work... So maybe temporary hack could be best and easiest solution before it would be fixed upstream? I want to update this applet during this or next weekend to make it usable for panels (I think that it is most typical place to put this kind of applet). Small off topic, I'm interested in moving my applets to KDE SVN playground. I've already requested and get SVN account and I've stupid question, do I need do something before try to commit them there? ;-) again, compositing and input masks. Thanks, but I still don't know what to do. ;-) I think that there could be added page on techbase or somewhere with collections of this kind of tips and tricks (not only tutorials, these things are probably too small to make own tutorial for each). For example I've earlier working on media player applet and I couldn't find (and still don't know, after some months) how to make it play file when created by dropping supported MIME on desktop (I've found this part, how to add it to menu) but I couldn't find which API part (or maybe something else) must be added to make applet open that file on init. the tray tracks the location of the QGraphicsWidget and manually positions the items. this is fraught with problems, though, such as not being able to be visible in more than one view at a time, not working when zoomed out ... same kinds of problems any manage a top level QWidget approach will face actually (c.f. the embed an application window plasmoid) But sadly not everything could be done clean now, but for temporary solutions kinds of these hacks could be used, but not forever and only if it is not possible to do it better. if you have specific questions, we can certainly answer them (and add it to the apidox as well) The problem was in KDE 4.1 docs (there was no description for this enumerator), now I see that for KDE 4.2 this is fixed, but I see that descriptions are probably in wrong lines in source: http://api.kde.org/4.2-api/kdelibs-apidocs/plasma/html/namespacePlasma.html#a48d70b0c4dcabb6dfbd8dfedb964eea But your example with widgets and containment is very interesting. One thing is clear (at least for me ;-)), that using applet's activate signal for unhiding autohidden panels should be separated from activation that comes from activation of applet's keyboard shortcut, because when you want also to use it to perform action yes, that's a good point. so we could use this same thing in that case as well. so now we just need some sort of name for this :) we have releaseVisualFocus() ... so .. requestVisualFocus(bool)? releaseVisualFocus would remain a heavy handed hide things! signal, and requestVisualFocus would allow one to ask for visual focus or to notify it isn't needed anymore. maybe it should be two method? i just can't think of two good names for it :) anyone else? I've seen similar names in Tasks applet. ;-) requestVisualFocus(bool) seems to be good name for it. I've more suggestions about current status of keyboard shortcuts for applets, but these should be discussed separately. ;-) sure thing (and yes, there's more work to be done there, indeed!) Ok, so probably I'll start new thread later today, now I'm tired (when I was answering to your message it was 2 AM in my time zone, and yes, I'm saying to myself that I should go sleep earlier but this usually doesn't help when I'm working on something :-D). thing is that hiding is an attribute of the View, not the Containment. plasmoids that only work on some views (PanelView) but not others (DesktopView, DashboardView, MIDView, etc) are no-nos. so i think this is something that should go directly into PanelView itself. I'm not familiar with this part of Plasma internals currently, so I simply don't
Clocks context menu to fast copying date and time
Hello So I've finally started using this mailing list so I would like to post here some of my ideas that accumulated for some time... Some time ago I've created wish on BKO: https://bugs.kde.org/show_bug.cgi?id=173162 I'm still interested in working on this topic, and I've plans how it could be achieved. Firstly there could be added default contextualActions() to ClockApplet. It would return by default one action, lets name it clipboardMenu. This action contains menu connected to it. The hovered() signal of this action could be connected to not public slot (or public, then it could be used by developers that want to supply own formats, like me), lets name it updateClipboardMenu(). That slot would update actions in that menu, removing or updating all actions in it using for example loop with list of predefined date and time formats (this list should differ from that in KDE3, it produced often duplicated entries). It would use dataEngine(time)-query(currentTimezone()) for getting current date and time (so there is no problem if clock is updated in interval other than one second). Every action would be connected (for example trigerred(QAction*) signal) to not public slot (could be named copyToClipboard()) for copying string from action to clipboard, using QApplication::clipboard()-setText(action-text()). If developers are interested and there is no objections I could try to create patch during this or next weekend. I'm already using this code in my applet for nearly half of year and it doesn't make any problems. There is only one problem, I don't have KDE from SVN and currently I don't have time to get it, so I would need someone to test it (writing it's not a problem for me). By the way, there is one virtual method that could be probably implemented in lib, because it probably will look the same in 95% of clock applets (I've noticed it when I was investigating why using wheel in my applet doesn't change time zone), I'm talking about this method: virtual void changeEngineTimezone(const QString oldTimezone, const QString newTimezone) Best regards Michał ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Adding history to pastebin plasmoid.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/483/ --- (Updated 2009-03-31 04:38:08.731243) Review request for Plasma. Changes --- Fixing minor issues (KDE coding style) Summary --- Adding history to pastebin plasmoid. Plasmoid should show the last 3 links shown by the plasmoid (when you click with the right button), and it should be copied to clipboard when user click on it. Diffs (updated) - trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.h 945384 trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.cpp 945384 Diff: http://reviewboard.kde.org/r/483/diff Testing --- Thanks, Danilo Cesar ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Adding history to pastebin plasmoid.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/483/#review753 --- trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.cpp http://reviewboard.kde.org/r/483/#comment450 Yes. topSeparator was used to separate Paste action from Pastebin Settings. As I'm adding new items under that action, it would be nice to have another separator on the bottom at that list. - Danilo Cesar On 2009-03-31 04:38:08, Danilo Cesar Lemes de Paula wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/483/ --- (Updated 2009-03-31 04:38:08) Review request for Plasma. Summary --- Adding history to pastebin plasmoid. Plasmoid should show the last 3 links shown by the plasmoid (when you click with the right button), and it should be copied to clipboard when user click on it. Diffs - trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.h 945384 trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.cpp 945384 Diff: http://reviewboard.kde.org/r/483/diff Testing --- Thanks, Danilo Cesar ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Clocks context menu to fast copying date and time
On Tuesday 31 March 2009 13:05:32 Emdek wrote: If developers are interested and there is no objections I could try to create patch during this or next weekend. I'm already using this code in my applet for nearly half of year and it doesn't make any problems. Sounds like a useful feature. :) Make sure you implement it in libplasmaclock so all clocks can benefit... There is only one problem, I don't have KDE from SVN and currently I don't have time to get it, so I would need someone to test it (writing it's not a problem for me). Hmm, you'd better get an svn checkout. In my experience it is near impossible to create good working code without actually testing the code. Depending on somebody else to do all the testing, is kind of... inconvenient. And what if some bug is reported that is related to this feature? There's no way for you to really debug the problem if it isn't very trivial. Also, it's not that much work (most of it is waiting), and if you haven't got a trunk checkout, what version of KDE are you going to patch? Anyway, welcome to plasma! Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Clocks context menu to fast copying date and time
Sounds like a useful feature. :) Make sure you implement it in libplasmaclock so all clocks can benefit... Of course, that is what I'm talking about. ;-) Hmm, you'd better get an svn checkout. In my experience it is near impossible to create good working code without actually testing the code. Depending on somebody else to do all the testing, is kind of... inconvenient. Yes, I know, but I don't have enough hard drive space and for this small patch it is too big overhead I think. The code is already implemented and tested (half of year and no reports, I'm using it every day starting from KDE 4.1 and I've also didn't noticed any problems), it only need to be extracted and modified in one place (in my clock you can configure available formats, globally it is not needed). This patch would consist of about thirty lines of code (so could be marked as trivial), and would add only three methods without conflicts with existing code (as far as I know there is no default list of contextual actions for ClockApplet, at least for 4.2). I could create patches for 4.2 and 4.1, only difference would be different offsets in files. The biggest problem for me is only there that I never created any patch, but I think that Kompare should help me to accomplish generation of patch file. ;-) Anyway, welcome to plasma! Thanks, it's nice to also giving and not only using results of others work. :-) Best regards Michał ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Adding history to pastebin plasmoid.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/483/#review755 --- Ship it! i'm really not sold on the bottom separator; that should be up to the Applet/Containment to make it fit properly into the overall menu. in any case, the code looks alright... thanks for the patch, please commit. - Aaron On 2009-03-31 04:38:08, Danilo Cesar Lemes de Paula wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/483/ --- (Updated 2009-03-31 04:38:08) Review request for Plasma. Summary --- Adding history to pastebin plasmoid. Plasmoid should show the last 3 links shown by the plasmoid (when you click with the right button), and it should be copied to clipboard when user click on it. Diffs - trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.h 945384 trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.cpp 945384 Diff: http://reviewboard.kde.org/r/483/diff Testing --- Thanks, Danilo Cesar ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Adding history to pastebin plasmoid.
On Tuesday 31 March 2009 12:42:12 Aaron Seigo wrote: Ship it! case, the code looks alright... thanks for the patch, please commit. If you do not have commit access, just tell me and I can commit for you =) Cheers, -- Artur Duque de Souza OpenBossa Research Labs INdT - Instituto Nokia de Tecnologia -- Blog: http://labs.morpheuz.eng.br/blog/ GPG: 0xDBEEAAC3 @ wwwkeys.pgp.net -- 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: Signals and slots for containment show and hide actions (mainly for panels)
On Tuesday 31 March 2009, Emdek wrote: - in my Run Command plasmoid that uses KHistoryComboBox to make it work in panels (I've created report about problems with them and others on GraphicsView); this is working around a problem in QGraphicsScene/View, really; it will get fixed (it's being worked on) so there's no reason to hack around it today. there may even be other ways to do it nicely with the combo being manually shown as the popup for the applet, which would also keep the panel from hiding. They are working on this bug? Finally, thanks for information. :-) np... But I hoped that this will be fixed for Qt 4.5... unfortunately we knew it wasn't going to be in 4.5; we're hoping for 4.5 though. I'm not sure if Qt 4.6 will be released in this year, so it could be possible that users (including myself ;-)) would need to wait probably for KDE 4.5 in mid 2010. But what can I do now with this? one thought i've had is to subclass it and provide a custom showPopup/hidePopup that takes the view() and positions is using Applet::popupPosition still wouldn't get proper context menus on the line edit, but at least the combobox would work :) typical place to put this kind of applet). Small off topic, I'm interested in moving my applets to KDE SVN playground. I've already requested and get SVN account and I've stupid question, do I need do something before try to commit them there? ;-) playground is open for anyone to put whatever they are working on in there. you don't need to ask anyone permission. the only real requirement is that stuff in playground/base/plasma is plasma related and builds. :) again, compositing and input masks. Thanks, but I still don't know what to do. ;-) I think that there could be added page on techbase or somewhere with collections of this kind of tips and tricks (not only tutorials, these things are probably too small to make own tutorial for each). For example I've earlier working on media player applet and I couldn't find (and still don't know, after some months) how to make it play file when created by dropping supported MIME on desktop (I've found this part, how to add it to menu) but I couldn't find which API part (or maybe something else) must be added to make applet open that file on init. look at the frame plasmoid perhaps. and maybe you could write a small tutorial on techbase with what you've found? the tray tracks the location of the QGraphicsWidget and manually positions the items. this is fraught with problems, though, such as not being able to be visible in more than one view at a time, not working when zoomed out ... same kinds of problems any manage a top level QWidget approach will face actually (c.f. the embed an application window plasmoid) But sadly not everything could be done clean now, but for temporary solutions kinds of these hacks could be used, but not forever and only if it is not possible to do it better. these kinds of hacks become permanent very easily. it's best to not let them in at all, and we certainly can't make changes to libplasma's public api for temporary hacks as that api must remain BC and hopefully clean. maybe it should be two method? i just can't think of two good names for it :) anyone else? I've seen similar names in Tasks applet. ;-) requestVisualFocus(bool) seems to be good name for it. ok, let's go for this then ... I've more suggestions about current status of keyboard shortcuts for applets, but these should be discussed separately. ;-) sure thing (and yes, there's more work to be done there, indeed!) Ok, so probably I'll start new thread later today, now I'm tired (when I was answering to your message it was 2 AM in my time zone, and yes, I'm saying to myself that I should go sleep earlier but this usually doesn't help when I'm working on something :-D). i know the feeling :) there possibility to restrict (disallow placing or show warning) usage of applet to given type of containment / view? no, and that's purposeful. the last thing we want are objects that only work in some places, because not only is that counter to the design goal of widgets that work everywhere but as a plasmoid author you have no idea what containment might appear next. it's a way of keeping the details of the outside world away from plasmoids so that they aren't full of odd work arounds and limitations. For example this manual hiding plasmoid would make sense only for hideable containments / views. But sure, and that's up to the view to decide. maybe there is, or could be in future, way to query Plasma for existing containments of given type and offer to user list of them - when more than one - when for example on desktop. and then when we introduce a different kind of view or containment, then all these plasmoids would probably break and/or do odd things. This could be used also for quick unhide all panels button for example.
Re: Clocks context menu to fast copying date and time
On Tuesday 31 March 2009, Emdek wrote: there is no default list of contextual actions for ClockApplet, at least for 4.2). I could create patches for 4.2 and 4.1, only difference would be we can probably merge patches from 4.2; note that it gets harder over time though as the branches diverge due to development. what you *could* do is just grab trunk/KDE/kdebase/workspace/ (it's about 230 MB in size, in total) since it builds on its own and just build in workspace/libs/plasmaclock/ ... if that's too much or, you could even just grab trunk/KDE/kdebase/workspace/libs/plasmaclock and put those sources into your 4.2 sources. if you have a 4.2 check out, you could even do: cd kdebase/workspace/libs/plasmaclock svn switch svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase/workspace/libs/plasmaclock/ . and then just that one directory would be trunk :) Anyway, welcome to plasma! Thanks, it's nice to also giving and not only using results of others work. :-) :) -- 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: Clocks context menu to fast copying date and time
On Tuesday 31 March 2009, Emdek wrote: different offsets in files. The biggest problem for me is only there that I never created any patch, but I think that Kompare should help me to accomplish generation of patch file. ;-) ah, forgot to comment on this bit: if you have an svn checkout (e.g. of 4.2) then you can just do: svn diff mypatch.diff if you are working from a release tarball, then you'll need a pristine copy of the sources and then you can just use the diff command directly from the command line: diff path/to/pristine/sources/ path/to/modified/sources mypatch.diff -- 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: The option Date for plasmoid Notes.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/415/ --- (Updated 2009-03-31 09:08:07.227460) Review request for Plasma. Changes --- Some modification and new screenshot. now the label date are down with smaller font and more distinguishable from the input text . Summary --- This patch adds to the plasmoid notes the possibility to show the (updated) date when a note is created(modified) . If you notice any problems with this new option just tell me Diffs (updated) - trunk/KDE/kdeplasma-addons/applets/notes/notes.cpp 947486 trunk/KDE/kdeplasma-addons/applets/notes/notes.h 947486 trunk/KDE/kdeplasma-addons/applets/notes/config.ui 947486 Diff: http://reviewboard.kde.org/r/415/diff Testing --- Screenshots (updated) --- http://reviewboard.kde.org/r/415/s/87/ http://reviewboard.kde.org/r/415/s/88/ Thanks, Sylvain ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Clocks context menu to fast copying date and time
On Tuesday 31 March 2009, Emdek wrote: Hello So I've finally started using this mailing list so I would like to post here some of my ideas that accumulated for some time... Some time ago I've created wish on BKO: https://bugs.kde.org/show_bug.cgi?id=173162 I'm still interested in working on this topic, and I've plans how it could be achieved. Firstly there could be added default contextualActions() to ClockApplet. It would return by default one action, lets name it clipboardMenu. This action contains menu connected to it. makes sense ... If developers are interested and there is no objections I could try to create patch during this or next weekend. I'm already using this code in my applet for nearly half of year and it doesn't make any problems. sure thing :) send it to the list or post it on reviewboard.kde.org (though if it doesn't apply cleanly, reviewboard will have problems with it; probably best to just send it to the list in this case) By the way, there is one virtual method that could be probably implemented in lib, because it probably will look the same in 95% of clock applets (I've noticed it when I was investigating why using wheel in my applet doesn't change time zone), I'm talking about this method: virtual void changeEngineTimezone(const QString oldTimezone, const QString newTimezone) yes, a default implementation would make sense here indeed. in fact, if we added a setTimeUpdateInterval(int ms) to ClockApplet, then it could be replaced quite easily in most cases. it's really just the update interval (and how that's controlled/configured) that's the reason this is reimplemented in every clock. -- 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: Unable to load images for pushbuttons from relative path
On Tuesday 31 March 2009, Eitzenberger Thomas wrote: Hi, someone on #plasma told me i could ask for help via this emailaddr too I need a pushbutton in the parley applet to trigger playing the sound file The button shall show up green if the url is valid and orange if not, grey if checking/ongoing Up to now I was only able to get the pushbutton showing up with the images using absolute URLS I tried with widgets/play_green.png widgets/play_green and also tried to embedd teh images in to the svg file but there I am stranded as the PushButton doesnt want a QPixmap but a path QString. png files shouldn't be installed into the theme, as it only deals with svg files. i can think of a couple of different ways to go about this: * install the png's into apddata and then use KStandardDirs to find it, e.g.: KGlobal::dirs()-locate(appdata, parley/play_green.png); * put all of the png's into an svg file, install that into the theme as you have done and then we could add to the widget API something like: void setImage(const QString path, const QString elementId) that would paint just the svg element from the svg, much as IconWidget does. this would only work for kde 4.3 and beyond, however. thoughts? -- 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 keyboard navigation to plasma applet Folder View
On 2009-03-20 14:07:32, Fredrik Höglund wrote:
/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp, line 1255
http://reviewboard.kde.org/r/368/diff/2/?file=3392#file3392line1255
The implementation of this function suffers from the same problem as
the one above.
It should also use the smoothScroll() function instead of changing the
scrollbar value directly.
I would implement it by doing something like:
const QRect r = mapFromViewport(visualRect(index));
if (r.top() 0) {
smoothScroll(0, r.top());
} else if (r.bottom() geometry().height()) {
smoothScroll(0, r.bottom() - geometry().height());
}
I've reverted whole of this back, and currently will work on this problem of
user having rearranged the icons. Will submit a new patch when I'm done.
- Shantanu
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/368/#review541
---
On 2009-03-20 22:14:51, Shantanu Tushar Jha wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/368/
---
(Updated 2009-03-20 22:14:51)
Review request for Plasma.
Summary
---
This partly addresses the above bug, adding keyboard navigation and launch
using Enter key.
Please report if the code is too complex, I've tried my best to keep it to
the point.
This addresses bug 187241.
https://bugs.kde.org/show_bug.cgi?id=187241
Diffs
-
/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.h 942106
/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 942106
Diff: http://reviewboard.kde.org/r/368/diff
Testing
---
Tested on latest SVN build. Navigation and launch work fine. The problem is
with movement of the scrollbar with the keyboard focus, the scrollbar refuses
to go to minimum value when m_scrollBar-setValue( m_scrollBar-minimum() );
is used. What am I doing wrong?
Thanks,
Shantanu
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add keyboard navigation to plasma applet Folder View
On 2009-03-20 14:07:32, Fredrik Höglund wrote: /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp, line 1208 http://reviewboard.kde.org/r/368/diff/2/?file=3392#file3392line1208 A problem with the way this function is implemented is that it assumes that the view is always sorted and that the icons always flow from left to right. When the user has rearranged the icons (m_layoutBroken is true), you have to assume that the icons are no longer arranged in a grid and that the visual order no longer matches the order in the model. When this is the case, and the user has pressed the up key for example, you have to iterate over all the icons and find the one that is closest to the current icon while still being above it. you have to iterate over all the icons. I'm working on this by iterating all icons and finding the nearest one to the current selection according to the key pressed, but the code is getting really complex in terms of calculations. I was wondering if there is any other way of doing this? If anyone has an idea, please let me know. Till then I'm working on it. - Shantanu --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/368/#review541 --- On 2009-03-20 22:14:51, Shantanu Tushar Jha wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/368/ --- (Updated 2009-03-20 22:14:51) Review request for Plasma. Summary --- This partly addresses the above bug, adding keyboard navigation and launch using Enter key. Please report if the code is too complex, I've tried my best to keep it to the point. This addresses bug 187241. https://bugs.kde.org/show_bug.cgi?id=187241 Diffs - /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.h 942106 /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 942106 Diff: http://reviewboard.kde.org/r/368/diff Testing --- Tested on latest SVN build. Navigation and launch work fine. The problem is with movement of the scrollbar with the keyboard focus, the scrollbar refuses to go to minimum value when m_scrollBar-setValue( m_scrollBar-minimum() ); is used. What am I doing wrong? Thanks, Shantanu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Signals and slots for containment show and hide actions (mainly for panels)
one thought i've had is to subclass it and provide a custom showPopup/hidePopup that takes the view() and positions is using Applet::popupPosition still wouldn't get proper context menus on the line edit, but at least the combobox would work :) Thanks for suggestion, I'll try to look also into KHistoryComboBox sources, maybe I'll find something interesting here. But there is still problem with focus of editable fields, at least in panels when there are visible windows. I've noticed it also in my other plasmoid (Spell Check) that uses dialog for displaying text edit etc. I was trying to use something like this: m_textEdit-setFocus(); Maybe problem comes from Qt::NoFocus focus flag for dialog? Or maybe Plasma can't be active window (isn't it required for giving focus for children?) when there are other not iconified windows? I've noticed problems that could come from that when I was working on task manager and I was trying to check if window is active. And one small thing, I've noticed bug in example of usage Plasma::ToolTipManager in docs (it will work only when using methods). Is there maybe better place for reporting such as small bugs? Sorry for next off topic, but these problems are so small that additional message only for them doesn't make much sense. ;-) playground is open for anyone to put whatever they are working on in there. you don't need to ask anyone permission. the only real requirement is that stuff in playground/base/plasma is plasma related and builds. :) Ok, thanks. :-) look at the frame plasmoid perhaps. and maybe you could write a small tutorial on techbase with what you've found? As far as I remember I've checked this plasmoid then (probably here I've found needed entries in .desktop file), also I was looking in sources of video player from playground. I'll check them again soon. I could try with tutorial but then someone should review it, because as can you see my English is not perfect. ;-) these kinds of hacks become permanent very easily. it's best to not let them in at all, and we certainly can't make changes to libplasma's public api for temporary hacks as that api must remain BC and hopefully clean. Yes, of course, it is easy to forget about them or be too lazy to fix them when it becomes possible (or overlook upstream changes). i know the feeling :) ;-) there possibility to restrict (disallow placing or show warning) usage of applet to given type of containment / view? no, and that's purposeful. the last thing we want are objects that only work in some places, because not only is that counter to the design goal of widgets that work everywhere but as a plasmoid author you have no idea what containment might appear next. it's a way of keeping the details of the outside world away from plasmoids so that they aren't full of odd work arounds and limitations. Ok, I see the point. Anyway, I think that if for example applet is not meant for use in panel like containments it could check formFactor() and location() and show warning to user etc. you've got some interesting ideas here that you should try experimenting with to see how they look and feel. the plasmoid approach breaches the barrier between widget, containment and view so probably isn't workable, but what you describe here should be doable all within PanelView in workspace/plasma/shells/desktop/ ... Right, I could do some research later. I'm thinking in general about experiments with alternative panel (trying to add some functionality requested by users and possibly working on alternative configuration interface) and this could include experiments with manual hiding. But before that I would like to finish work on some of my applets. And again about thread with suggestions for shortcuts, I need to check better current possibilities in 4.2 (to not suggest something that could be already achieved ;-)) and then I'll start new thread. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Google Summer of Code
*Good morning/day/night, Plasma team!* *My name is Alexander Argutin and I’m a 3-d grade student of South Ural State University in Chelyabinsk, Russian Federation. I’m writing you a letter because I found interesting an idea of the GSoC, so I would like to take this chance. Why so late?)) Maybe because is too late and short summer in Russia)* *According to the Application template on a site, every GSoC student candidate should give info about himself and his proposed project. Here it is:* *Name: **Alexander Argutin* *Email Address: **Alex dot Argutin at gmail dot com* *Freenode IRC Nick: **Hornman* *Location (City, Country and/or Time Zone): **Chelyabinsk, Russian Federation, GMT +5:00 (Yekaterinburg)* *Proposal Name:* New Widget Explorer (from ideas list)** *Motivation for Proposal / Goal:** What differs developers and users? …except their abilities of coding)... Developers know what they want from the computer and applications. And that’s why there is a problem for developers – how to create soft that will explain user what does he want. **Today developers have all equipment to do it: *translucent widgets of a streamline, animated effects of soft light and shadow, reflexions etc... There are no more boundaries of a desktop, no more statics, no more obstacles for understanding between a user and a computer. *This project is a step to* a lightweight widget-oriented UI concept. Main goal is to bring a visitor to a widget-library, to let him make a choice easily and to make him understand that all his dreams are true and most of his problems will be solved easily by doing a few clicks... *Implementation Details:* Developing Phases: *Phase 0 (5%):* Common architecture building, learning technologies, asking questions. This step brings knowledge about KDE and Plasma environment, structures of an application and its basic functional blocks. The most general questions concerning architecture, and concerning realization are being asked to the mentor at this stage. On this step application will be divided on such blocks as: - Search Block SB will solve problems of looking for a widget, sorting widgets and rating explosion. - View block VB will solve problems of easy and comfortable UI with a controller functions (MVC scheme) - Adoption block AB will be the most capacious and also will be divided. It will solve problems of widget support, placing, install and launch. *Phase 1 (20%):* Designing UI and usability analysis This stage assumes designing of the UI according to the standards of usability, graphic effects, and the whole application view. This stage comes at the beginning of the development because the design is one of the most significant parts of this project. *Phase 2 (10%):* UML architecture building, creating a kernel concept This phase consists from construction of diagrams of precedents, classes and logic design of a product. Main objective of this stage is working out of the flexible architecture, supporting all predictable widgets and third party services. *Phase 4 (30%):* Designing interfaces, business-logic and project features *Phase 3 (45%):* Developing main project blocks prototypes Phase of main coding and algorithmization. *Phase 4 (60%):* Assembling main blocks. Beta *Phase 5 (70%):* Beta-testing and cleaning bug-reports This stage means removing all bugs and holes found in a project. *Phase 7 (85%): *Ending development Finishing main parts, realization of the third party widgets, trying different platforms, and little features realisation. *Phase 8 (100%):* Release *Tentative Timeline:** If the work will be started *at the first days of April, Beta version will be expected in the first decade of June. If succeeds, all the work will be done till the end of July – beginning of August. *Do you have other obligations from late May to early August (school, work, etc.)?*: I will have to pass the exams at the end of June. That’s all serious plans for this time if the project will live. I don’t think my study will affect my work on project or vice versa, because I study at university only perfectly well. *About Me (let us know who you are!): **F*irst of all I’m a student. And I like this condition because it feels cool to be a student! =) I like computers and all things linked to them: gadgets, devices, coding, gaming, business-modeling, even the programming of microprocessors in assembler language... Once I’ve chosen this path I’ve never felt sorry about it. Why? Of course because it’s future! Unfortunately, there is no magic in our world like in games, but there is a technology, so isn’t it a power? So, my heart is in the IT sphere…) There are many things I can tell about myself. I like creative activities and respect people who is engaged in them. That’s why I like music and poetry. What about my own future? I don’t think it’s predictable, but I always try to make it happy. *Yours faithfully, Alexander.*
Google summer of code proposal : kde and social desktop.
Hi. I'm an student in IT Engineering in University of Parma , italy. I'd want to apply for the Social-desktop project and i's want to share some idea with you. I think the whole proposal is very well descripted in http://techbase.kde.org/Projects/Social-Desktop. My idea is to develop some plasmoid for kde: 1) Friends (find people that use kde near the user, become friend, see friend activity on kde sites) 2) Official News (rss feed with new improvement, event. The easiest one) 3) Help (place for the connection with help guide,forums,mailing lists and bug tracking) Thanks. Nicola ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Clocks context menu to fast copying date and time
___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Clocks context menu to fast copying date and time
If developers are interested and there is no objections I could try to create patch during this or next weekend. I'm already using this code in my applet for nearly half of year and it doesn't make any problems. sure thing :) send it to the list or post it on reviewboard.kde.org (though if it doesn't apply cleanly, reviewboard will have problems with it; probably best to just send it to the list in this case) I could try with reviewboard first, I could create patch using fresh checkout of lib to avoid problems. yes, a default implementation would make sense here indeed. in fact, if we added a setTimeUpdateInterval(int ms) to ClockApplet, then it could be replaced quite easily in most cases. it's really just the update interval (and how that's controlled/configured) that's the reason this is reimplemented in every clock. So I could create additional patch for this. It could also add four protected methods, for setting and getting values of interval and alignment. What do you think about this? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Google Summer of Code
hi Александр :) On Tuesday 31 March 2009, Александр Аргутин wrote: *Good morning/day/night, Plasma team!* *My name is Alexander Argutin and I’m a 3-d grade student of South Ural State University in Chelyabinsk, Russian Federation. I’m writing you a letter because I found interesting an idea of the GSoC, so I would like to take this chance. Why so late?)) Maybe because is too late and short summer in Russia)* please submit this to the Google SoC site: http://code.google.com/soc/ otherwise we can not consider your application ... thanks :) -- 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: Signals and slots for containment show and hide actions (mainly for panels)
On Tuesday 31 March 2009, Emdek wrote: one thought i've had is to subclass it and provide a custom showPopup/hidePopup that takes the view() and positions is using Applet::popupPosition still wouldn't get proper context menus on the line edit, but at least the combobox would work :) Thanks for suggestion, I'll try to look also into KHistoryComboBox sources, maybe I'll find something interesting here. But there is still problem with focus of editable fields, at least in panels when there are visible windows. yes, the panel doesn't ever get keyboard focus. that's something we need to work out as well ... basically, we need to know when a widget that can use keyboard focus in a meaningful way gets focus. in kicker, everything was an x window, so it could grab focus independently without requiring the whole panel to do so. with alien widgets or widgets on canvas, we don't have that shortcut available to us. And one small thing, I've noticed bug in example of usage Plasma::ToolTipManager in docs (it will work only when using methods). Is there maybe better place for reporting such as small bugs? if there's something incorrect in the apidox, please feel free to just fix them up and commit :) Sorry for next off topic, but these problems are so small that additional message only for them doesn't make much sense. ;-) yeah, it's all good :) look at the frame plasmoid perhaps. and maybe you could write a small tutorial on techbase with what you've found? As far as I remember I've checked this plasmoid then (probably here I've found needed entries in .desktop file), also I was looking in sources of video player from playground. I'll check them again soon. I could try with tutorial but then someone should review it, because as can you see my English is not perfect. ;-) if you post the link here, i'm sure several of us would be happy to review it and fix any errors :) -- 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: Clocks context menu to fast copying date and time
On Tuesday 31 March 2009, Emdek wrote: If developers are interested and there is no objections I could try to create patch during this or next weekend. I'm already using this code in my applet for nearly half of year and it doesn't make any problems. sure thing :) send it to the list or post it on reviewboard.kde.org (though if it doesn't apply cleanly, reviewboard will have problems with it; probably best to just send it to the list in this case) I could try with reviewboard first, I could create patch using fresh checkout of lib to avoid problems. ok.. and if that doesn't work out, then the list should work out ok. yes, a default implementation would make sense here indeed. in fact, if we added a setTimeUpdateInterval(int ms) to ClockApplet, then it could be replaced quite easily in most cases. it's really just the update interval (and how that's controlled/configured) that's the reason this is reimplemented in every clock. So I could create additional patch for this. It could also add four protected methods, for setting and getting values of interval and alignment. What do you think about this? i think that would be great; centralizing more of the common code can only be a good thing :) -- 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: Google summer of code proposal : kde and social desktop.
On Tuesday 31 March 2009, nicky.7 wrote: Hi. I'm an student in IT Engineering in University of Parma , italy. I'd want to apply for the Social-desktop project and i's want to share some idea with you. I think the whole proposal is very well descripted in http://techbase.kde.org/Projects/Social-Desktop. My idea is to develop some plasmoid for kde: looks cool; be sure to submit it to the google site before the deadline so it can be considered for inclusion in the program: http://code.google.com/soc you may also want to include some mockups if you have them :) -- 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: Signals and slots for containment show and hide actions (mainly for panels)
yes, the panel doesn't ever get keyboard focus. that's something we need to work out as well ... basically, we need to know when a widget that can use keyboard focus in a meaningful way gets focus. in kicker, everything was an x window, so it could grab focus independently without requiring the whole panel to do so. with alien widgets or widgets on canvas, we don't have that shortcut available to us. Now I remember that there was an entry about making panels focusable in todo list for KDE 4.1 (or 4.2). I hope that it will be fixed soon (if currently possible). And one small thing, I've noticed bug in example of usage Plasma::ToolTipManager in docs (it will work only when using methods). Is there maybe better place for reporting such as small bugs? if there's something incorrect in the apidox, please feel free to just fix them up and commit :) I think that it would be safer if it could be done by someone that has more experience with SVN than me (I've never made SVN commit :-D) and I don't want to break compilation if I made kind of mistake. ;-) I could try with tutorial but then someone should review it, because as can you see my English is not perfect. ;-) if you post the link here, i'm sure several of us would be happy to review it and fix any errors :) Ok, so if I'll find this and don't forget I could try to do, but I can't promise. :-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [GSoC] (One more) Proposal for Plasmate
we already have a previewer started in playground; showing a plasmoid in a little window by itself is a tiny amount of code, really. :) don't need to; we know where the code is on disk, and you can just pass that path directly to the Package which would then be used by the Applet object to run the widget. Evidently I have yet much to learn about the platform and available code :) * if the user needs an embedded terminal to make plasmate useful, something's horribly wrong :) it's all based on managing the contents of a Package and that's all automated / automatable So happened that when I was telling a friend about Plasmate he exclaimed 'What, no terminal!?' :P I agree completely that Plasmate should not need to rely on the terminal emulator at all, but I was just thinking that it might be handy (I use Kate's terminal for all kinds of things). Hmmm, then again Plasmate will probably be maintaining the 'project files' somewhere out of sight so maybe its not such a good idea to let the user have terminal access to that location after all. * for the diff viewer, we could probably use the kdiff kpart that comes with kde if it's available on the system (otherwise just show it in a plain text editor, i suppose) Yeah, was thinking the same thing. Wonder how much work will it be though to manually produce one from a text diff file. Since it doesn't need to be editable, the hardest part would probably be parsing the diff file Thanks a lot for the comments by the way :) Will have them addressed before the deadline this friday . *fingers crossed* Lim Yuen Hoe http://yuenhoe.co.cc/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Clocks context menu to fast copying date and time
i think that would be great; centralizing more of the common code can only be a good thing :) Ok, so probably during weekend I'll create both patches and put them on reviewboard (I'm unavailable from Wednesday to Friday - classes at school...). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Gsoc Proposal Telepathy-Plasma Integration
Hi guys. I was studying the telepathy framework and finished my Gsoc proposal. Please could you provide some feedback , suggestions on this? http://docs.google.com/Doc?id=dcg3n3b6_7f7337bfk I already received some comments from a Decibel developer about the telepathy part, but would like to receive comments from Plasma developers too. Thanks Ronny ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-devel Digest, Vol 9, Issue 100
Hi Thomas, the solution is quite simple; you have to use use the applicationDirPath() method to retrieve the app location; then combine it to get the full path for your imgs. ( however, if you have tons of images, how about using resources ? ) Here it is the explanation http://doc.trolltech.com/4.4/qcoreapplication.html#applicationDirPath Cheers ! 2009/3/31 plasma-devel-requ...@kde.org Send Plasma-devel mailing list submissions to plasma-devel@kde.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.kde.org/mailman/listinfo/plasma-devel or, via email, send a message with subject or body 'help' to plasma-devel-requ...@kde.org You can reach the person managing the list at plasma-devel-ow...@kde.org When replying, please edit your Subject line so it is more specific than Re: Contents of Plasma-devel digest... Today's Topics: 1. Unable to load images for pushbuttons from relative path (Eitzenberger Thomas) -- Messaggio inoltrato -- From: Eitzenberger Thomas e...@gmx.at To: plasma-devel@kde.org Date: Tue, 31 Mar 2009 10:10:43 +0200 Subject: Unable to load images for pushbuttons from relative path Hi, someone on #plasma told me i could ask for help via this emailaddr too I need a pushbutton in the parley applet to trigger playing the sound file The button shall show up green if the url is valid and orange if not, grey if checking/ongoing Up to now I was only able to get the pushbutton showing up with the images using absolute URLS I tried with widgets/play_green.png widgets/play_green and also tried to embedd teh images in to the svg file but there I am stranded as the PushButton doesnt want a QPixmap but a path QString. Any help would be appreciated... For discussions you can find my also on skype (user EItzenberger Thomas) and on MSN (user e...@gmx.at) Thanx for any feedback ___ 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
Re: Review Request: Add keyboard navigation to plasma applet Folder View
On 2009-03-20 14:07:32, Fredrik Höglund wrote:
/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp, line 1208
http://reviewboard.kde.org/r/368/diff/2/?file=3392#file3392line1208
A problem with the way this function is implemented is that it assumes
that the view is always sorted and that the icons always flow from left to
right.
When the user has rearranged the icons (m_layoutBroken is true), you
have to assume that the icons are no longer arranged in a grid and that the
visual order no longer matches the order in the model.
When this is the case, and the user has pressed the up key for example,
you have to iterate over all the icons and find the one that is closest to
the current icon while still being above it.
wrote:
you have to iterate over all the icons. I'm working on this by
iterating all icons and finding the nearest one to the current selection
according to the key pressed, but the code is getting really complex in terms
of calculations. I was wondering if there is any other way of doing this? If
anyone has an idea, please let me know. Till then I'm working on it.
I would do something like this (the example is for the up key only):
QModelIndex nextIndex = QModelIndex();
QPoint currentPos = visualRect(currentIndex).center();
int lastDistance = 0;
for (int i = 0; i m_validRows; i++) {
const QModelIndex index = m_model-index(i, 0);
const QPoint pos = visualRect(index).center();
if (pos.y() currentPos.y()) {
int distance = (pos - currentPos).manhattanLength();
if (distance lastDistance || !currentIndex.isValid()) {
nextIndex = index;
lastDistance = distance;
}
}
}
If nextIndex is valid when you get here, it's the index you should move to.
If it isn't valid there are no icons above the current icon.
Thanks for working on this feature :)
- Fredrik
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/368/#review541
---
On 2009-03-20 22:14:51, Shantanu Tushar Jha wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/368/
---
(Updated 2009-03-20 22:14:51)
Review request for Plasma.
Summary
---
This partly addresses the above bug, adding keyboard navigation and launch
using Enter key.
Please report if the code is too complex, I've tried my best to keep it to
the point.
This addresses bug 187241.
https://bugs.kde.org/show_bug.cgi?id=187241
Diffs
-
/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.h 942106
/trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 942106
Diff: http://reviewboard.kde.org/r/368/diff
Testing
---
Tested on latest SVN build. Navigation and launch work fine. The problem is
with movement of the scrollbar with the keyboard focus, the scrollbar refuses
to go to minimum value when m_scrollBar-setValue( m_scrollBar-minimum() );
is used. What am I doing wrong?
Thanks,
Shantanu
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-devel Digest, Vol 9, Issue 100
On Tuesday 31 March 2009, Diego Casella wrote: Hi Thomas, the solution is quite simple; you have to use use the applicationDirPath() method to retrieve the app location; then combine it to get the full path for your imgs. that won't work unless the application (e.g. plasma-desktop) is in the same directory as the image. which isn't the case. :) -- 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
Systemtray benchmarks
these are some benchmark (probably not realy accurate) should give a really gross idea.. i measured the time elased to convert to pass 1000 icons 32x32 argb32 a) converting to png passing the data over dbus and uncompressing again, 10 runs: 3.442 3.404 3.474 3.262 3.254 3.474 3.354 3.584 3.415 3.363 average 3.403 seconds 293.858 icons/second b) passing uncompressed raw data, (just image.bits() copied) 2.620 2.656 2.512 2.584 2.588 2.560 2.541 2.552 2.584 2.520 average 2.572 seconds 388.802 icons/second that's faster, even if not mindboggling faster still not tried with pixmap handles, should be way faster, but still think portability concerns are way too much now, with png is where the code and the api is simpler/nicer but is the slowest with raw data it would be compatibe with toolkits that don't have png (there are things with dbus support where png could be a prblem? seems unlikely but..) s, opinions? :) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasmate Proposal - added some changes and screenshots
Hello guys, I made some changes on my PlasMate proposal, and also I added a screenshot about the main window ( I think the element placement is pretty nice and clean =P ). In this moment it only opens a file, and shows it in the editor field; however take a look and tell me your impressions. http://socghop.appspot.com/document/show/user/diego_casella/plasmate Best regards, Diego. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systemtray benchmarks
Hi Marco, Just my 2 cents here. If the uncompressed raw data works and it's not an unmaintainable beast, I'd go for it for the simple fact that having to compress-transmit-decompress could be not so handy and sounds more like a hack. If I got you right: decompress means back to raw data? If so, I'd really prefer the second approach. Adding png would be an useless layer of complexity, I think. And, as a bonus point, if your benchmarks are correct, it looks to me that the performance gain is kinda remarkable. It would be nice to see the code of both approaches to get a better idea on it. Oh, forgot to say: great work :) On Tuesday 31 March 2009 23:04:45 Marco Martin wrote: these are some benchmark (probably not realy accurate) should give a really gross idea.. i measured the time elased to convert to pass 1000 icons 32x32 argb32 a) converting to png passing the data over dbus and uncompressing again, 10 runs: 3.442 3.404 3.474 3.262 3.254 3.474 3.354 3.584 3.415 3.363 average 3.403 seconds 293.858 icons/second b) passing uncompressed raw data, (just image.bits() copied) 2.620 2.656 2.512 2.584 2.588 2.560 2.541 2.552 2.584 2.520 average 2.572 seconds 388.802 icons/second that's faster, even if not mindboggling faster still not tried with pixmap handles, should be way faster, but still think portability concerns are way too much now, with png is where the code and the api is simpler/nicer but is the slowest with raw data it would be compatibe with toolkits that don't have png (there are things with dbus support where png could be a prblem? seems unlikely but..) s, opinions? :) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B 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: Plasmate Proposal - added some changes and screenshots
Any change of QtCreator (/KDevelop) integration? Looks pretty nice btw :-) Cheers, Kenneth On Tue, Mar 31, 2009 at 6:21 PM, Diego Casella polentino...@gmail.com wrote: Hello guys, I made some changes on my PlasMate proposal, and also I added a screenshot about the main window ( I think the element placement is pretty nice and clean =P ). In this moment it only opens a file, and shows it in the editor field; however take a look and tell me your impressions. http://socghop.appspot.com/document/show/user/diego_casella/plasmate Best regards, Diego. ___ 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
Re: Systemtray benchmarks
On Tuesday 31 March 2009, Dario Freddi wrote: Hi Marco, Just my 2 cents here. If the uncompressed raw data works and it's not an unmaintainable beast, I'd go for it for the simple fact that having to compress-transmit-decompress could be not so handy and sounds more like a hack. If I got you right: decompress means back to raw data? If so, I'd really prefer the second approach. Adding png would be an useless layer of complexity, I think. agreed. it's guaranteed to be usable by everyone, even weirdos without png support ;) , and looks faster. so +1 for that. for the 10 icons in my system tray right now, it would take ~25-30ms to transfer them. that's approximately 40x faster than it currently takes just one of the icons to show up in the tray right now. wow. Oh, forgot to say: great work :) +1 -- 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
April 7 soft feature freeze
hi all just a quick reminding there April 7 is the soft feature freeze for 4.3. that means that a feature must at least be on the feature plan, and best is if they are at least started in svn. don't get caught out! :) it would be great to see some of the plugins sitting in kdereview move out. -- 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: Systemtray benchmarks
On Tuesday 31 March 2009 23:04:45 Marco Martin wrote: these are some benchmark (probably not realy accurate) should give a really gross idea.. i measured the time elased to convert to pass 1000 icons 32x32 argb32 I'm interested: could you also run this benchmark for 96x96 icons, which is often used for the icon in notification icons? Currently it also uses png's to transfer this data, but it wouldn't surprise me if with those bigger icons png's are faster. Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Much less flickering when there is no backing store
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/488/#review765 --- seems the diff didn't make it; can you update the diff again, and if that doesn't work just send it to the list? thanks. - Aaron On 2009-03-31 15:53:55, David Nolden wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/488/ --- (Updated 2009-03-31 15:53:55) Review request for Plasma. Summary --- Remember the background image used for the tray-icon, and do not update it if it has not changed. The following XClearArea call leads to a very annoying flicker when the backing-store is disabled, and to the user, it happens at totally random occasions. Unfortunately this can only be implemented cheaply for the raster engine, since there does not seem to be an efficient way to compare QPixmap's. Diffs - trunk/kdebase/workspace/plasma/applets/systemtray/protocols/fdo/x11embedcontainer.cpp 940781 Diff: http://reviewboard.kde.org/r/488/diff Testing --- Thanks, David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Much less flickering when there is no backing store
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/488/ --- (Updated 2009-03-31 17:09:28.786838) Review request for Plasma. Summary --- Remember the background image used for the tray-icon, and do not update it if it has not changed. The following XClearArea call leads to a very annoying flicker when the backing-store is disabled, and to the user, it happens at totally random occasions. Unfortunately this can only be implemented cheaply for the raster engine, since there does not seem to be an efficient way to compare QPixmap's. Diffs (updated) - trunk/kdebase/workspace/plasma/applets/systemtray/protocols/fdo/x11embedcontainer.cpp 940781 Diff: http://reviewboard.kde.org/r/488/diff Testing --- Thanks, David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
