Re: Now Playing Urls
On Friday 18 September 2009 20:04:22 Aaron J. Seigo wrote: On September 17, 2009, Alex Merry wrote: On Thursday 17 September 2009 18:05:59 you wrote: Hi, Not all script engines (e.g. webkit) can use QPixmap from the data and sometimes file path is useful (if artwork is not set I would like to show jpg from the same dir). This patch adds Url ArtUrl fields to data. Ok to commit or should I find another solution? Well, the only thing that concerns me is that if the widget and engine are on different machines (which is entirely possible, since one of the GSoC projects was to allow just that), the URLs will not be valid for the widget. that's correct; paths that are not reachable over the network are not ok if the widget is expected to be able to work over the network at all. one way to work around this would be to implement a system that lets one open files using KIO via either the DataEngine or AccessManager which would handle where to open the file from. but if this really is just to work around webkit not being able to access pixmap data, that's really something certainly can be worked around in the webkit script engine. I can live without arturl but url would be handy even if it is not valid. If there is no metadata I would like to use file name so there is something to show to the user. Other option would be to set pattern in dataengine so it could parse the directory and file name but I'm not sure if that belongs there. Petri 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: Dataengines, libs and default config
On Friday 18 September 2009 21:43:20 Aaron J. Seigo wrote: On September 18, 2009, Petri Damstén wrote: Currently making a weather applet is much harder in scripting languages because you don't have access to the library. can't you build some QScript bindings for it? then the applet can request that add-on? Yes of course but I was thinking some common way that would not require generating bindings for all available scritpengines. there are a few ways to go about this: a) go around making bindings for multiple languages over and over. not realistic, imo b) create a generic interface to specific kinds of things that then each script engine maintainer can look after c) concentrate on the JS bindings and make those top tier and not worry too much about whether there are equal features in every single script engine. (c) is what i'd like to see us do. there are already differences between the script engines (obvious ones like google gadgets vs pythonoids; less obvious ones like python libs that aren't available in ruby). we really ought to be promoting JS as the preferred way to write plasmoids anyways and given that we have limited resources and no suitable CLR type thing realistically at our disposal, let's just concentrate on QSCript here. so.. what would it look like? i think most sensible would be a way to register families of widget types (weather, clock, etc). perhaps we can call them widget foundations, since you build on top of them? each foundation would provide a factory for creating instances of an applet with some QScript hooks that can be exported into the runtime, perhaps as part of an object named foundation? I think most of the kde-look.org plasmoids are made with python (quick check from 20 highest rated is about 90%). I personally don't like the idea of letting those to be second class citizens. Petri 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
Review request: Container plasma applet
Hi! I've added in kdereview/plasma/applets an applet i made recently. It is, as the name suggests, an applet that lets you contain and group other applets. You can put it on the desktop or on the panel and then drag other applets from the add applet widget inside it. it puts the applet in a grid layout and it uses a spacer like the one in the panel to tell you where the applet will be put if you release the mouse. Then you can move the applets inside the layout. It supports the drop and creation of icons plasmoid from the entries from kickoff too. When you put it in the panel you can choose, through a check box in the configuration dialog if you want it to behave like a PopupApplet or like a simple Applet. Currently it needs an icon, because the question mark you can see now if you use it as a PopupApplet isn't so cool. I searched through the icon chooser but I coul not find an icon that suited my taste. This plasmoid solves requests like https://bugs.kde.org/show_bug.cgi?id=193015 and others i saw on the bug tracker and on the brainstorm. Giulio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Changes in PlasMate editor component.
Hi Shantanu, I had some time on my hands this weekend so I went on ahead and decided to do some work with the PlasMate editor component in an attempt to make it able to actually load project files when they are clicked. Just letting you know since the editor is technically your domain :) As always this is new stuff for me so if I do anything horridly wrong (or you just don't like my changes) feel free to fix/revert. Just drop me a note :) Best regards, -- Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QCA2 and Remote Widgets
On Sunday 06 September 2009, Dario Freddi wrote: In data domenica 06 settembre 2009 18:47:05, Rob Scheepmaker ha scritto: : On Sunday 06 September 2009 16:49:36 Dario Freddi wrote: : Hello people, we do have a problem! The new remote widgets in plasma are requiring QCA2 to make things work out. The problem is that by now, QCA2 is an optional package for KDELibs, and when it is not found, there are no checks in plasma that will prevent things needing QtCrypto (the remotewidgets authorizer) from being thrown off the build. Oops... Somehow I was under the impressioon QCA2 was already a required package. My fault as well, I did not notice that in the first place while helping you push the stuff :) Rob, is it possible at the moment to compile libplasma without QCA2/Remote Widgets? If so, please tell me how so that I can come up with a fix to this. Otherwise, we have to get through k-c-d requesting another hard dependency for KDELibs Compiling without Remote Widgets suppor is not yet possible at the moment, but I can make sure it won't be required. All QCA related code is only in one class: Credentials. I can add some cmake stuff and ifdefs to make sure validSignature() always returns false and canSign always returns false in case of a missing QCA. This makes sure accessRemoteApplet and publish() always just plain fails. This one is a valuable option, we can spit a phat warning if QCA2 is not installed in the optional packages. KAuth at the moment has a similar behavior on linux if polkit-qt is not found. I should probably return no remoteApplets in AccessManager as well so we don't list zeroconf announced plasmoids in places that do that (soon the new widget explorer for example), since you won't be able to connect anyways without QCA. This also would be even nicer I'm now dealing with some personal stuff, but I'm sure I'll have the time tomorrow to fix this, and make QCA2 an optional dependency for libplasma. Take your time, 4.4 is far away :) My primary concern was wheter to trigger a discussion on having yet another hard dependency on kdelibs. Just ping me back when you're done with this It still doesn't build on my machine: [ 94%] Building CXX object plasma/CMakeFiles/plasma.dir/package.o In file included from /home/alex/src/kde4-svn/KDE dir/kdelibs/plasma/package.cpp:45: /home/alex/src/kde4-svn/KDE dir/kdelibs/plasma/private/authorizationmanager_p.h:29:20: error: QtCrypto: No such file or directory In file included from /home/alex/src/kde4-svn/KDE dir/kdelibs/plasma/package.cpp:45: /home/alex/src/kde4-svn/KDE dir/kdelibs/plasma/private/authorizationmanager_p.h:72: error: 'QCA' has not been declared /home/alex/src/kde4-svn/KDE dir/kdelibs/plasma/private/authorizationmanager_p.h:72: error: ISO C++ forbids declaration of 'Initializer' with no type /home/alex/src/kde4-svn/KDE dir/kdelibs/plasma/private/authorizationmanager_p.h:72: error: expected ';' before 'initializer' make[2]: *** [plasma/CMakeFiles/plasma.dir/package.o] Error 1 make[1]: *** [plasma/CMakeFiles/plasma.dir/all] Error 2 make: *** [all] Error 2 Please add proper checks for QCA. Alex ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: devicenotifier with qgw
On September 19, 2009, Jacopo De Simoi wrote: 1) we need to activate the items on hover, but with the itemBackground animation delay, hoverEvent is not good anymore to track that. I can see two solutons: - itemBackground should send some signal when its animation finishes, something like targetReached(qgi *) where the pointer would be null if the target was not an item. - itemBackground should make publicly available the animation time, so that we can animate accordingly fadein/fadeout in each item. i can see uses for both, really. the problem with providing an animation time is that it will never be perfectly timed; what would be better is for the item background to emit a signal whenever it gets an animation update due to its internal animation. then another animation can synchronize with it. perhaps emit something between 0 and 1, with 1 == target has been reached? worth experimenting with, in any case. 2) we need a way to destroy the hover when the mouse leaves all items; i as marco notes, this really isn't needed. just call hide or setTarget(0) yourself. -- 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 Development Frameworks 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: Dataengines, libs and default config
On September 20, 2009, Petri Damstén wrote: I think most of the kde-look.org plasmoids are made with python (quick check from 20 highest rated is about 90%). I personally don't like the idea of letting those to be second class citizens. obviously the majority of scripted widgets right now are going to be mostly python: * python is well known * the python engine has complete bindings available for it we're not going to see JS applets until we have complete bindings for them and otherwise encourage the use of JS. it's circular logic to say well, we don't see many JS widgets, so we shouldn't work on JS support. so, is it worth having JS widgets? well, the downsides of python are dependencies, runtime weight and no ability to provide a version of them that is reasonably securable. the upsides of JS are going to be size of audience (JS is probably the #1 dynamic language in the world in terms of people who have been exposed to it by a far margin), security, performance, greater portability and ease of integration with things like web content. there's also something to be said about consistency. JS makes the most sense for in-app scripting when we look at the full body of KDE applications and to think that our target users will learn multiple languages just to drive various applications well is really naive. so it's not about making Python a second class citizen, it's about giving JS the support we ought to be giving it and realizing that we only have so many resources to get scripting language support in. and yes, i think it's pretty insert expletive stupid that we have seen all this effort put into python and ruby while the much better target is left with far too little attention and what attention it gets is by people who haven't had much bindings experience in the past. there's some real big picture thinking missing here. -- 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 Development Frameworks 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: QCA2 and Remote Widgets
On Saturday 19 September 2009, 09:23 Alexander Neundorf wrote:
It still doesn't build on my machine:
Please add proper checks for QCA.
I think that he already did that:
if(QCA2_FOUND)
include_directories(${QCA2_INCLUDE_DIR})
set(ENABLE_REMOTE_WIDGETS TRUE)
endif(QCA2_FOUND)
So, try a clean build please...
Cheers!
--
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
--
Blog: http://blog.morpheuz.cc
PGP: 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: Generic view widget for Plasma
On September 18, 2009, David Palacio wrote: * The private Plasma::Style should be extended to let the scrollarea and view items be painted in the current theme style. we already have one item delegate in libplasma, we i suppose we could have another. exporting Plasma::Style is not an option as we have no idea whether that what we can commit to in the longer term. * Export the different view widgets to Plasma. this is a possibility. i was half-waiting for the new Qt M/V stuff to emerge, but i suppose we can only hold our breath for so long. iirc Lancelot and FolderView both have some M/V integration. the device notifier being ported to QGV will also need something. given that work and its usefulness to the kate/konsole/etc sessions plasmoids, a list widget would likely be a welcome addition. i would like to see us avoid forcing people to use Qt's rather painful M/V API just to get a nice list, however. so it should be a feature rather than a requirement to use such a Plasma::Widget. Or Chani's desktop menu launcher if you're referring to the ContainmentActions plugin, i don't think there is anything that can or should be done about this. Reimplementation of the konsole profiles widget as a folderview http://imagebin.ca/view/Ayp-Nz.html is this a mockup or have you actually ported the konsole profiles? i'm not sure that using folderview's list widget is really the best of ideas. if you take a look at the existing delegate in libplasma, you can see some of the current requirements. and again, Jacopo and Giulio are working on the device notifier to take it in this direction, so maybe they could end up creating a nice generic list widget out of that for use by others? -- 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 Development Frameworks 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: devicenotifier with qgw
On September 20, 2009, Aaron J. Seigo wrote: On September 19, 2009, Jacopo De Simoi wrote: 1) we need to activate the items on hover, but with the itemBackground animation delay, hoverEvent is not good anymore to track that. I can see two solutons: - itemBackground should send some signal when its animation finishes, something like targetReached(qgi *) where the pointer would be null if the target was not an item. - itemBackground should make publicly available the animation time, so that we can animate accordingly fadein/fadeout in each item. i can see uses for both, really. the problem with providing an animation time is that it will never be perfectly timed; what would be better is for another thing that occurred to me just now while responding to David Placio's email: perhaps you could create a generic listing widget for inclusion in lib plasma and then use ItemBackground internally to make this magic work without having to export more API for it? not sure if that would work out perfectly, but if having such a list widget in libplasma would make this easier, let's consider doing that. -- 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 Development Frameworks 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: Container plasma applet
On September 20, 2009, Giulio Camuffo wrote: I've added in kdereview/plasma/applets an applet i made recently. It is, as the name suggests, an applet that lets you contain and group other applets. this functionality belongs in a Containment, not an Applet. we have two applets right now that can contain other applets: system tray and system monitor. the latter has had numerous bugs and is, to be frank, an implementation mistake. there is nothing that could not have been done much easier and with less hacking around stuff if system monitor had not been written to embed the various system monitor applets directly. the design of Plasma is such that the Containment-Applet relationship is quite carefully crafted and solves a lot of issues. ContainerWidget::drop which does not support various features found in Containment is a good example of this. i think it's a nice candidate for publishing on kde-look.org and you can certainly put it into extragear if you'd like, but the concept is problematic from a design perspective and will cause inconsistencies and other problems if we ship it with Plasma. given Containments have complete freedom on how to manage, group, etc. Applets, focusing these kinds of efforts there would make a lot more sense. -- 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 Development Frameworks 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: Container plasma applet
I know that that functionality belongs in a Containment, but since containments in containments are not supported i had to use an Applet. And i know that this applet will never have all the functionalities the containments have, but this isn't my goal. I wanted to develop a simple applet to group other applets. I don't plan to implement e.g. the new feature that loads the applet depending on the mimetype dropped. I developed this also because I thought to do a plasmoid that was actually a set of plasmoids inserted in this applet. But if you say that this brings many bugs and headaches amybe i'll change my mind. I don't understand however why the systemtray isn't problematic while this one it is. I already published it on kde-look, and I'd say people like it, since it is already 80% good with only 73 downloads, but I thought it would be more discoverable to the people if it was inside KDE, since, from what I read, some people need it. Anyway, with your last sentence you was saying that I could have done a similar thing working directly on containments? Giulio 2009/9/20 Aaron J. Seigo ase...@kde.org On September 20, 2009, Giulio Camuffo wrote: I've added in kdereview/plasma/applets an applet i made recently. It is, as the name suggests, an applet that lets you contain and group other applets. this functionality belongs in a Containment, not an Applet. we have two applets right now that can contain other applets: system tray and system monitor. the latter has had numerous bugs and is, to be frank, an implementation mistake. there is nothing that could not have been done much easier and with less hacking around stuff if system monitor had not been written to embed the various system monitor applets directly. the design of Plasma is such that the Containment-Applet relationship is quite carefully crafted and solves a lot of issues. ContainerWidget::drop which does not support various features found in Containment is a good example of this. i think it's a nice candidate for publishing on kde-look.org and you can certainly put it into extragear if you'd like, but the concept is problematic from a design perspective and will cause inconsistencies and other problems if we ship it with Plasma. given Containments have complete freedom on how to manage, group, etc. Applets, focusing these kinds of efforts there would make a lot more sense. -- 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 Development Frameworks ___ 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
Remote Widgets Warning Message
Hello! :) Some people pointed me that it would be nice to have a message indicating the problems of adding a remote widget from an untrusted host. Like a warning or something like that to warn users that remote widgets may harm their PCs.. What do you think about ? Cheers! -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 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: Review request: Container plasma applet
On Sunday 20 September 2009, 14:10 Giulio Camuffo wrote: I know that that functionality belongs in a Containment, but since containments in containments are not supported i had to use an Applet. Hmmare you sure that containments inside containments are not supported ? =( Cheers, -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 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: Review request: Container plasma applet
On September 20, 2009 10:29:14 Artur Souza (MoRpHeUz) wrote: On Sunday 20 September 2009, 14:10 Giulio Camuffo wrote: I know that that functionality belongs in a Containment, but since containments in containments are not supported i had to use an Applet. Hmmare you sure that containments inside containments are not supported ? =( yes. -- This message brought to you by eevil bananas and the number 3. www.chani3.com 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: Container plasma applet
On Sunday 20 September 2009, Giulio Camuffo wrote: Hi! I've added in kdereview/plasma/applets an applet i made recently. It is, as the name suggests, an applet that lets you contain and group other applets. i'm just an ambassandor on that, but apparently it's missing Messages.sh You can put it on the desktop or on the panel and then drag other applets from the add applet widget inside it. it puts the applet in a grid layout and it uses a spacer like the one in the panel to tell you where the applet will be put if you release the mouse. Then you can move the applets inside the layout. It supports the drop and creation of icons plasmoid from the entries from kickoff too. When you put it in the panel you can choose, through a check box in the configuration dialog if you want it to behave like a PopupApplet or like a simple Applet. Currently it needs an icon, because the question mark you can see now if you use it as a PopupApplet isn't so cool. I searched through the icon chooser but I coul not find an icon that suited my taste. This plasmoid solves requests like https://bugs.kde.org/show_bug.cgi?id=193015 and others i saw on the bug tracker and on the brainstorm. Giulio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Bugs in signalplotter.cpp
Hi, not sure who's the responsible on that, blame says 73% of lines are from
leonhard but CIA says he left KDE time ago, copyright mentions John so i'm
mailing for John and plasma-devel (as replacement of leonhard).
In plasma/widgets/signalplotter.cpp there is code like this
foreach (QListdouble data, d-plotData) {
data.append(0);
}
foreach (QListdouble data, d-plotData) {
if (newOrder.count() != data.count()) {
kDebug() Serious problem in move sample. plotdata[i] has
data.count() and neworder has
newOrder.count();
} else {
QListdouble newPlot;
for (int i = 0; i newOrder.count(); i++) {
int newIndex = newOrder[i];
newPlot.append(data.at(newIndex));
}
data = newPlot;
}
}
foreach (QListdouble data, d-plotData) {
if ((uint)data.size() = pos) {
data.removeAt(pos);
}
}
This code does nothing, it is only working over temporary copies of the lists,
the orginal ones are not modified, please read
http://tsdgeos.blogspot.com/2008/04/qforeach-is-your-friend.html if you don't
understand what i say.
Albert
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Sunday 20 September 2009, Giulio Camuffo wrote: I know that that functionality belongs in a Containment, but since containments in containments are not supported i had to use an Applet. And i know that this applet will never have all the functionalities the containments have, but this isn't my goal. I wanted to develop a simple applet to group other applets. I don't plan to implement e.g. the new feature that loads the applet depending on the mimetype dropped. I developed this also because I thought to do a plasmoid that was actually a set of plasmoids inserted in this applet. But if you say that this brings many bugs and headaches amybe i'll change my mind. I don't understand however why the systemtray isn't problematic while this one it is. well, it's a bit problematic indeed actually, one of the reasons the config ui only permits to add a tiny supset of the applets, for 2 reasons what there could make sense from an user pov but most important excluding the ones that will break. (and have already to lie about the real formfactor to not make it explode in the desktop) I already published it on kde-look, and I'd say people like it, since it is already 80% good with only 73 downloads, but I thought it would be more discoverable to the people if it was inside KDE, since, from what I read, some people need it. Anyway, with your last sentence you was saying that I could have done a similar thing working directly on containments? Giulio 2009/9/20 Aaron J. Seigo ase...@kde.org On September 20, 2009, Giulio Camuffo wrote: I've added in kdereview/plasma/applets an applet i made recently. It is, as the name suggests, an applet that lets you contain and group other applets. this functionality belongs in a Containment, not an Applet. we have two applets right now that can contain other applets: system tray and system monitor. the latter has had numerous bugs and is, to be frank, an implementation mistake. there is nothing that could not have been done much easier and with less hacking around stuff if system monitor had not been written to embed the various system monitor applets directly. the design of Plasma is such that the Containment-Applet relationship is quite carefully crafted and solves a lot of issues. ContainerWidget::drop which does not support various features found in Containment is a good example of this. i think it's a nice candidate for publishing on kde-look.org and you can certainly put it into extragear if you'd like, but the concept is problematic from a design perspective and will cause inconsistencies and other problems if we ship it with Plasma. given Containments have complete freedom on how to manage, group, etc. Applets, focusing these kinds of efforts there would make a lot more sense. -- 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 Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: netbook irc meeting
On Thursday 17 September 2009, Marco Martin wrote: Hi all, since i want to do the netbook shell as good as possible, i'm interested to hear opinions and directions from you guys =D i would like to have a little irc meeting about it, to discuss some of the issues there still are in the current implementation, possible topics are: -point of the situation, what actually are the issues :) -integration with the system, like with kwin, and how to start a netbook session -default applets layout, what to put in the containments -look and feel: how should actually look from a designe pov -priorities: what is really important for 4.4, what can be 4.5 more implementation details, not really metting topics: -how to loadthe default layout: hardcode/vs default config fie/vs scripting -what are the ugly spots in the code and things like that could be done? what do you think? Cheers, Marco Martin in the end being aaron and nuno-less there wasn't much going on, however me and arthur chatted a bit about the various parts for a bit, here is the unfiltered log that can at least make a recap of the topics if we can make a good one :) [19:04] igorto notmart, MoRpHeUz me and Savago are talking about a personal layout .. using akonadi(akonadi dataengine maybe) [19:04] Savago tumaix, just FISL. But it was great. Meet with lots of former co-workers there. :-) [19:05] notmart igorto, MoRpHeUz: the social activity thing? [19:05] MoRpHeUz igorto: ? [19:05] MoRpHeUz notmart: I don't think it's the same thing hehe [19:05] notmart ah, ok [19:06] MoRpHeUz notmart: I was thinking more about OCS and Silk, but yeah, for other contact stuff we should use akonadi for sure [19:06] igorto notmart, no ... a layout for contacts(vcard), notes, todos, with google synchronization and these things [19:06] notmart MoRpHeUz: that's looks like just a default applets layout, really [19:06] Savago yep. The good thing is that all this stuff is already done by akonadi (protocols, data formats, etc). [19:06] MoRpHeUz notmart: I really don't care about the layout of the stuffcan be newspaper, default applets layout, etc... [19:07] notmart for silk, i wanted to do a mini-selkie plasmoid that opens the full selkie.. [19:07] MoRpHeUz notmart: I'm more interested about the *contents* of the thing hehe [19:07] Savago MoRpHeUz, what were you planning for the *contents*? [19:07] notmart MoRpHeUz: so the question becomes: do we already have all the plasmoids we need? [19:08] notmart for default layout i was meaning, what sets of plasmoid should be loaded by default [19:08] MoRpHeUz notmart: that's one problem, I think that right now the number of default plamoids that we should have are growing, and that's why a separate activity would be needed [19:09] MoRpHeUz (imagine a scenario with 15 contact plasmoids) [19:09] MoRpHeUz Savago: something like what you said above, but not centered on akonadi stuff [19:09] MoRpHeUz something more like what moblin provides [19:09] MoRpHeUz (and open desktop widget) [19:09] notmart MoRpHeUz: yes, but also keep in mind that having an awful load of stuff loaded by default makes the memory footprint pretty big [19:10] notmart and if it is the user that adds stuff is ok, but there shouldn't be the impression that as default is really bloated [19:10] Savago MoRpHeUz, I see. [19:10] * pinheiro nost sure i like a big page of plasmoids or several pages [19:11] notmart we should also have a way to add/remove pages that possibly isn't the zui there.. [19:11] MoRpHeUz notmart: yep, I'm talking about the user adding stuff (after all, it's the users contacts) [19:12] MoRpHeUz notmart: so, as pinheiro pointed out it's a matter of having a big page of plasmoids or several pages... [19:12] -- fawek has left this server (Read error: 104 (Connection reset by peer)). [19:12] pinheiro notmart: maybe scrolingn trough pages is more interesting than the zui here [19:12] pinheiro more phinger friendly [19:13] notmart what i'm more concerned for this meeting however, is to really have clear in mind what is a must have for 4.4 and must be rushed in quickly :D [19:13] pinheiro and as space manegemenat is simpler for the user [19:13] notmart pinheiro: a single long page that scrolls? [19:14] pinheiro notmart: no several pages [19:14] pinheiro that you can push [19:14] pinheiro slide [19:14] pinheiro like desktops [19:14] -- nhnFreespirit has left this server (Read error: 110 (Connection timed out)). [19:15] MoRpHeUz notmart: well, for 4.4 I think that having what we currently have but really stable and a way to easily switch between netbook and desktop shells [19:15] MoRpHeUz it would be ok for the first release [19:15] * pinheiro agfreas [19:16] pinheiro agreas [19:16] MoRpHeUz notmart: and then the social stuff for later, to really improve the user experience... [19:16] notmart the sliding animation could be a problem since we aren't sure the pages on the scene are in the right order.. [19:16] *
Re: Review Request: adding default colors format for kolourpicker and support for latex colors.
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1669/#review2405
---
Ship it!
to me apart some style issues looks good
/trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp
http://reviewboard.kde.org/r/1669/#comment1705
whitespace
/trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp
http://reviewboard.kde.org/r/1669/#comment1706
we always use
if (!act) {
return;
}
/trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp
http://reviewboard.kde.org/r/1669/#comment1707
brackets
- Marco
On 2009-09-20 18:24:15, Tomaz Canabrava wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1669/
---
(Updated 2009-09-20 18:24:15)
Review request for Plasma.
Summary
---
remvoes the default menu that appears whenever we want to pick a color, not
it uses a default colorstring format to do that, the color string format
should be choosen before picking colors ( click on the round color button, go
to Default Color Format and choose your favorite one), then just pick colors
without the annoying menu popping everytime.
Also, added support for latex colors.
Diffs
-
/trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.h 1026067
/trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp 1026067
Diff: http://reviewboard.kde.org/r/1669/diff
Testing
---
everything working, no regressions found, no new bugs introduced ( from my
tests )
Thanks,
Tomaz
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: adding default colors format for kolourpicker and support for latex colors.
On 2009-09-20 18:51:25, Marco Martin wrote: to me apart some style issues looks good just a thing: since it changes the behaviour a bit contact the original author of it (pinotree on irc) - Marco --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1669/#review2405 --- On 2009-09-20 18:24:15, Tomaz Canabrava wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1669/ --- (Updated 2009-09-20 18:24:15) Review request for Plasma. Summary --- remvoes the default menu that appears whenever we want to pick a color, not it uses a default colorstring format to do that, the color string format should be choosen before picking colors ( click on the round color button, go to Default Color Format and choose your favorite one), then just pick colors without the annoying menu popping everytime. Also, added support for latex colors. Diffs - /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.h 1026067 /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp 1026067 Diff: http://reviewboard.kde.org/r/1669/diff Testing --- everything working, no regressions found, no new bugs introduced ( from my tests ) Thanks, Tomaz ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: disappearing
On Thursday 17 September 2009 19:39:26 Dario Freddi wrote: i just want to let you know that the hd of my new laptop broke down as well (damn, the third in less than three months ¬¬), so that's the reason why I completely disappeared after tokamak... As soon as Acer will give it back to me, I'll come back though. :-) and will finish that damn train clock ;-) lies! back. yeee :D -Riccardo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Generic view widget for Plasma
Sorry I am not properly replying. I am not subscribed and forgot to tell you that. /me subscribes. Aarón Seigo escribió: On September 18, 2009, David Palacio wrote: * The private Plasma::Style should be extended to let the scrollarea and view items be painted in the current theme style. we already have one item delegate in libplasma, we i suppose we could have another. I saw that. It does not work properly with a simple QStringListModel and the View still feels out of place. The latter is because a delegate only styles items, it misses the background and frame. That is why I think extending the Plasma style is the best option. exporting Plasma::Style is not an option as we have no idea whether that what we can commit to in the longer term. Of course. But if view widgets were exported from kdelibs, they could use the private extended style. * Export the different view widgets to Plasma. this is a possibility. i was half-waiting for the new Qt M/V stuff to emerge, but i suppose we can only hold our breath for so long. iirc Lancelot and FolderView both have some M/V integration. the device notifier being ported to QGV will also need something. given that work and its usefulness to the kate/konsole/etc sessions plasmoids, a list widget would likely be a welcome addition. i would like to see us avoid forcing people to use Qt's rather painful M/V API just to get a nice list, however. so it should be a feature rather than a requirement to use such a Plasma::Widget. Or Chani's desktop menu launcher if you're referring to the ContainmentActions plugin, i don't think there is anything that can or should be done about this. It is always possible :) Reimplementation of the konsole profiles widget as a folderview http://imagebin.ca/view/Ayp-Nz.html is this a mockup or have you actually ported the konsole profiles? You could call it a mockup. The two widgets to the left are actually folderviews. For each profile I created a .desktop link. The Qt one includes Assistant, Designer and Creator links. i'm not sure that using folderview's list widget is really the best of ideas. if you take a look at the existing delegate in libplasma, you can see some of the current requirements. and again, Jacopo and Giulio are working on the device notifier to take it in this direction, so maybe they could end up creating a nice generic list widget out of that for use by others? That is the idea. A grid or tree view widget with a custom delegate would be great as well. 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: Generic view widget for Plasma
On Sunday 20 September 2009, Aaron J. Seigo wrote: On September 18, 2009, David Palacio wrote: * The private Plasma::Style should be extended to let the scrollarea and view items be painted in the current theme style. we already have one item delegate in libplasma, we i suppose we could have another. exporting Plasma::Style is not an option as we have no idea whether that what we can commit to in the longer term. * Export the different view widgets to Plasma. this is a possibility. i was half-waiting for the new Qt M/V stuff to emerge, but i suppose we can only hold our breath for so long. iirc Lancelot and FolderView both have some M/V integration. the device notifier being ported to QGV will also need something. we have a mv-ish in various places don't know about lancelot -folderview uses qt models and does custom painting of all the items in a single actual qgraphicswidget -krunner and the netbook sal uses a qgw per item and no qt models -the mediacenter uses a qgw per item but qt models not sure what is the best approach... implementing similar things over and over again is really not good, but i kinda feel a -really- working mv implementation in our api is really a big commitment for us (and would be thrown away anyways) couldn't we live with graphicswidgets in a scrollwidget for a while? (but yeah, we can hold our breath for so long..) given that work and its usefulness to the kate/konsole/etc sessions plasmoids, a list widget would likely be a welcome addition. i would like to see us avoid forcing people to use Qt's rather painful M/V API just to get a nice list, however. so it should be a feature rather than a requirement to use such a Plasma::Widget. Or Chani's desktop menu launcher if you're referring to the ContainmentActions plugin, i don't think there is anything that can or should be done about this. Reimplementation of the konsole profiles widget as a folderview http://imagebin.ca/view/Ayp-Nz.html is this a mockup or have you actually ported the konsole profiles? i'm not sure that using folderview's list widget is really the best of ideas. if you take a look at the existing delegate in libplasma, you can see some of the current requirements. and again, Jacopo and Giulio are working on the device notifier to take it in this direction, so maybe they could end up creating a nice generic list widget out of that for use by others? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: netbook irc meeting
On Sunday 20 September 2009, Marco Martin wrote: On Thursday 17 September 2009, Marco Martin wrote: Hi all, since i want to do the netbook shell as good as possible, i'm interested to hear opinions and directions from you guys =D i would like to have a little irc meeting about it, to discuss some of the issues there still are in the current implementation, possible topics are: -point of the situation, what actually are the issues :) -integration with the system, like with kwin, and how to start a netbook session -default applets layout, what to put in the containments -look and feel: how should actually look from a designe pov -priorities: what is really important for 4.4, what can be 4.5 more implementation details, not really metting topics: -how to loadthe default layout: hardcode/vs default config fie/vs scripting -what are the ugly spots in the code and things like that could be done? what do you think? Cheers, Marco Martin in the end being aaron and nuno-less there wasn't much going on, however me and arthur chatted a bit about the various parts for a bit, here is the unfiltered log that can at least make a recap of the topics if we can make a good one :) little synopsys, topics were mostly what we more urgently need for 4.4: *Panel: -default applets: now there are current window control, activitybar, spacer, systray, search field for sal - i would swap current window control and the search field - connected to the ability to have multiple pages (just tought about it now) a button after activitybar that creates a new newspaper activity - other thing not touched there but to be decided: panel autohide or not? - search field for sal: since the sal has a search field by itself i would do: -make it no longer a popupapplet so i can access the dialog geometry -make the dialog be exactly superimposed to the sal internel search field to make it feel they are the same thing *Newspaper -titles: on mouse over like applet handles or always there? (applet handles like would be waay simpler code, less clobbering with layouts) [19:04] igorto notmart, MoRpHeUz me and Savago are talking about a personal layout .. using akonadi(akonadi dataengine maybe) [19:04] Savago tumaix, just FISL. But it was great. Meet with lots of former co-workers there. :-) [19:05] notmart igorto, MoRpHeUz: the social activity thing? [19:05] MoRpHeUz igorto: ? [19:05] MoRpHeUz notmart: I don't think it's the same thing hehe [19:05] notmart ah, ok [19:06] MoRpHeUz notmart: I was thinking more about OCS and Silk, but yeah, for other contact stuff we should use akonadi for sure [19:06] igorto notmart, no ... a layout for contacts(vcard), notes, todos, with google synchronization and these things [19:06] notmart MoRpHeUz: that's looks like just a default applets layout, really [19:06] Savago yep. The good thing is that all this stuff is already done by akonadi (protocols, data formats, etc). [19:06] MoRpHeUz notmart: I really don't care about the layout of the stuffcan be newspaper, default applets layout, etc... [19:07] notmart for silk, i wanted to do a mini-selkie plasmoid that opens the full selkie.. [19:07] MoRpHeUz notmart: I'm more interested about the *contents* of the thing hehe [19:07] Savago MoRpHeUz, what were you planning for the *contents*? [19:07] notmart MoRpHeUz: so the question becomes: do we already have all the plasmoids we need? [19:08] notmart for default layout i was meaning, what sets of plasmoid should be loaded by default [19:08] MoRpHeUz notmart: that's one problem, I think that right now the number of default plamoids that we should have are growing, and that's why a separate activity would be needed [19:09] MoRpHeUz (imagine a scenario with 15 contact plasmoids) [19:09] MoRpHeUz Savago: something like what you said above, but not centered on akonadi stuff [19:09] MoRpHeUz something more like what moblin provides [19:09] MoRpHeUz (and open desktop widget) [19:09] notmart MoRpHeUz: yes, but also keep in mind that having an awful load of stuff loaded by default makes the memory footprint pretty big [19:10] notmart and if it is the user that adds stuff is ok, but there shouldn't be the impression that as default is really bloated [19:10] Savago MoRpHeUz, I see. [19:10] * pinheiro nost sure i like a big page of plasmoids or several pages [19:11] notmart we should also have a way to add/remove pages that possibly isn't the zui there.. [19:11] MoRpHeUz notmart: yep, I'm talking about the user adding stuff (after all, it's the users contacts) [19:12] MoRpHeUz notmart: so, as pinheiro pointed out it's a matter of having a big page of plasmoids or several pages... [19:12] -- fawek has left this server (Read error: 104 (Connection reset by peer)). [19:12] pinheiro notmart: maybe scrolingn trough pages is more interesting than the zui here [19:12] pinheiro more phinger friendly [19:13] notmart
Re: netbook irc meeting
On Sunday 20 September 2009, Marco Martin wrote: On Sunday 20 September 2009, Marco Martin wrote: On Thursday 17 September 2009, Marco Martin wrote: Hi all, since i want to do the netbook shell as good as possible, i'm interested to hear opinions and directions from you guys =D i would like to have a little irc meeting about it, to discuss some of the issues there still are in the current implementation, possible topics are: -point of the situation, what actually are the issues :) -integration with the system, like with kwin, and how to start a netbook session -default applets layout, what to put in the containments -look and feel: how should actually look from a designe pov -priorities: what is really important for 4.4, what can be 4.5 more implementation details, not really metting topics: -how to loadthe default layout: hardcode/vs default config fie/vs scripting -what are the ugly spots in the code and things like that could be done? what do you think? Cheers, Marco Martin in the end being aaron and nuno-less there wasn't much going on, however me and arthur chatted a bit about the various parts for a bit, here is the unfiltered log that can at least make a recap of the topics if we can make a good one :) little synopsys, topics were mostly what we more urgently need for 4.4: *Panel: -default applets: now there are current window control, activitybar, spacer, systray, search field for sal - i would swap current window control and the search field - connected to the ability to have multiple pages (just tought about it now) a button after activitybar that creates a new newspaper activity - other thing not touched there but to be decided: panel autohide or not? - search field for sal: since the sal has a search field by itself i would do: -make it no longer a popupapplet so i can access the dialog geometry -make the dialog be exactly superimposed to the sal internel search field to make it feel they are the same thing *Newspaper -titles: on mouse over like applet handles or always there? (applet handles like would be waay simpler code, less clobbering with layouts) uh, forgotten quite important topic: we agreed that as the default stuff in the newspaper could be good news, weather, opendesktop and opendesktop knowledgebase all of them are in kdeplasma-addons: is a acceptable dependency? :/ [19:04] igorto notmart, MoRpHeUz me and Savago are talking about a personal layout .. using akonadi(akonadi dataengine maybe) [19:04] Savago tumaix, just FISL. But it was great. Meet with lots of former co-workers there. :-) [19:05] notmart igorto, MoRpHeUz: the social activity thing? [19:05] MoRpHeUz igorto: ? [19:05] MoRpHeUz notmart: I don't think it's the same thing hehe [19:05] notmart ah, ok [19:06] MoRpHeUz notmart: I was thinking more about OCS and Silk, but yeah, for other contact stuff we should use akonadi for sure [19:06] igorto notmart, no ... a layout for contacts(vcard), notes, todos, with google synchronization and these things [19:06] notmart MoRpHeUz: that's looks like just a default applets layout, really [19:06] Savago yep. The good thing is that all this stuff is already done by akonadi (protocols, data formats, etc). [19:06] MoRpHeUz notmart: I really don't care about the layout of the stuffcan be newspaper, default applets layout, etc... [19:07] notmart for silk, i wanted to do a mini-selkie plasmoid that opens the full selkie.. [19:07] MoRpHeUz notmart: I'm more interested about the *contents* of the thing hehe [19:07] Savago MoRpHeUz, what were you planning for the *contents*? [19:07] notmart MoRpHeUz: so the question becomes: do we already have all the plasmoids we need? [19:08] notmart for default layout i was meaning, what sets of plasmoid should be loaded by default [19:08] MoRpHeUz notmart: that's one problem, I think that right now the number of default plamoids that we should have are growing, and that's why a separate activity would be needed [19:09] MoRpHeUz (imagine a scenario with 15 contact plasmoids) [19:09] MoRpHeUz Savago: something like what you said above, but not centered on akonadi stuff [19:09] MoRpHeUz something more like what moblin provides [19:09] MoRpHeUz (and open desktop widget) [19:09] notmart MoRpHeUz: yes, but also keep in mind that having an awful load of stuff loaded by default makes the memory footprint pretty big [19:10] notmart and if it is the user that adds stuff is ok, but there shouldn't be the impression that as default is really bloated [19:10] Savago MoRpHeUz, I see. [19:10] * pinheiro nost sure i like a big page of plasmoids or several pages [19:11] notmart we should also have a way to add/remove pages that possibly isn't the zui there.. [19:11] MoRpHeUz notmart: yep, I'm talking about the user adding stuff (after all, it's the users
Re: netbook irc meeting
On September 20, 2009, Marco Martin wrote: uh, forgotten quite important topic: we agreed that as the default stuff in the newspaper could be good news, weather, opendesktop and opendesktop knowledgebase all of them are in kdeplasma-addons: is a acceptable dependency? :/ not really; they can be added to the layout if they exist, though. looking at those choices, it would seem that the main layout is for checking the weather and using opendesktop. is that what people will do with this on a netbook? it seems that the idea is current events information (e.g. weather) and social networking (e.g. open desktop). perhaps the left column can be one and the right column the other, an perhaps we can have something more than just weather for current events? identi.ca might be a nice add to the social networking side and some RSS feeds might be a nice add to the current events column? -- 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 Development Frameworks 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: netbook irc meeting
On September 20, 2009, Marco Martin wrote: On Sunday 20 September 2009, Marco Martin wrote: On Thursday 17 September 2009, Marco Martin wrote: Hi all, since i want to do the netbook shell as good as possible, i'm interested to hear opinions and directions from you guys =D i would like to have a little irc meeting about it, to discuss some of the issues there still are in the current implementation, possible topics are: -point of the situation, what actually are the issues :) -integration with the system, like with kwin, and how to start a netbook session -default applets layout, what to put in the containments -look and feel: how should actually look from a designe pov -priorities: what is really important for 4.4, what can be 4.5 more implementation details, not really metting topics: -how to loadthe default layout: hardcode/vs default config fie/vs scripting -what are the ugly spots in the code and things like that could be done? what do you think? Cheers, Marco Martin in the end being aaron and nuno-less there wasn't much going on, however me and arthur chatted a bit about the various parts for a bit, here is the unfiltered log that can at least make a recap of the topics if we can make a good one :) little synopsys, topics were mostly what we more urgently need for 4.4: *Panel: -default applets: now there are current window control, activitybar, spacer, systray, search field for sal search field probably not needed now? (see below) (and you're missing clock there, no?) also, in systray there is: battery, networking, .. ? - i would swap current window control and the search field swap position you mean? if so, why? - connected to the ability to have multiple pages (just tought about it now) a button after activitybar that creates a new newspaper activity this could also be in the newspaper page itself to save space in the activitybar? - other thing not touched there but to be decided: panel autohide or not? i like the current behaviour for the default.. - search field for sal: since the sal has a search field by itself i would do: -make it no longer a popupapplet so i can access the dialog geometry -make the dialog be exactly superimposed to the sal internel search field to make it feel they are the same thing i don't think a separate applet for this is needed at all now, tbh. and if it's always in the panel, then we don't need the separate icon in the panel either. just focus the line edit when switching to it. *Newspaper -titles: on mouse over like applet handles or always there? (applet handles like would be waay simpler code, less clobbering with layouts) why would applet handles like be simpler? i'd think that always-there handles would be easier. what are the design goals for the handles? * provide access to close, maximize and configure. do we want a way to collapse an applet too? that's probably not strictly necessary. * finger friendly? (this may make it significantly harder to keep the spacing nice; perhaps there could be a size adjustment based on whether it's on a touch screen or not?) * widgets shouldn't move around whether the handle is visible or not * should hide when not hovered or selected? perhaps the handles can always be there and only the control buttons fade in when a widget is hovered? interesting to see how http://www.google.com/ig does it, too. -- 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 Development Frameworks 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: Generic view widget for Plasma
On September 20, 2009, David Palacio wrote: we already have one item delegate in libplasma, we i suppose we could have another. I saw that. It does not work properly with a simple QStringListModel and the View still feels out of place. The latter is because a delegate only styles items, it misses the background and frame. That is why I think extending the Plasma style is the best option. if the view remains in libplasma, the style can be extended, sure. that may not be necessary, though, depending on the approach. e.g. if you intend to create a QGraphicsProxyWidget that proxies a QListView then yes, you'd need a style. but i wonder what advantage there would be to that vs just creating a nice Plasma::ListView that is a simple QGraphicsWidget? exporting Plasma::Style is not an option as we have no idea whether that what we can commit to in the longer term. Of course. But if view widgets were exported from kdelibs, they could use the private extended style. yes -- 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 Development Frameworks 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: Generic view widget for Plasma
On September 20, 2009, Marco Martin wrote: couldn't we live with graphicswidgets in a scrollwidget for a while? (but yeah, we can hold our breath for so long..) the issue is that people keep reinventing that graphicswidget-in-a- scrollwidget and connecting up their models to it by hand. it would be nice to have something generic that can be shared. and yes, it will likely be thrown away eventually due to Qt always being about a year behind what our needs are. -- 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 Development Frameworks 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: Container plasma applet
On September 20, 2009, Giulio Camuffo wrote: I don't plan to implement e.g. the new feature that loads the applet depending on the mimetype dropped. this kind of inconsistency is exactly what keeps this kind of approach out of the main modules. why should the user be allowed to only do certain things in certain places due to implementation decisions? nah.. :) the user should be able to trust the rules and not have to do special things for special circumstances. (the fact that you have to, in practice anyways, open the panel toolbox to configure the tasks widget still bugs me :P) I developed this also because I thought to do a plasmoid that was actually a set of plasmoids inserted in this applet. what kind of plasmoid, exactly? (we may have other ideas on how to achieve this) I don't understand however why the systemtray isn't problematic while this one it is. the system tray is problematic. it works around a number of little things (though we did make some changes internal to libplasma to ease that as well), but the benefits outweigh the negatives. the system monitor, however, has all the negatives and no real benefits. so it's a case by case basis, and generally discouraged because the chance for regressions are high when changes get made (esp new features) in libplasma. I already published it on kde-look, and I'd say people like it, since it is already 80% good with only 73 downloads, but I thought it would be more discoverable to the people if it was inside KDE, since, from what I read, some people need it. honestly, people rarely know what they really need or even really want. imagine if we removed folderview tomorrow? and that was the most Evil Feature Ever(tm) a year ago. design with purpose, not by the popular opinion and whims of those on kdelook or other online sites populated by self-selecting hard core users. Anyway, with your last sentence you was saying that I could have done a similar thing working directly on containments? yes, and that's really probably the way to go about it. use cases would probably help define what direction to actually take. -- 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 Development Frameworks 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: Remote Widgets Warning Message
On September 20, 2009, Artur Souza (MoRpHeUz) wrote: What do you think about ? until the security checking is in place, this is premature. should check with pinda on this... -- 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 Development Frameworks 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
