Re: Review Request: Make the gridview behave correctly, no matter what icon size is set
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3494/ --- (Updated 2010-04-06 06:37:26.349194) Review request for Plasma, Marco Martin and Alessandro Diaferia. Changes --- Changed according to suggestions Summary --- In the future, we need to support different sizes for previews. This patch adds preliminary support for this to happen. The size can be set in setIconSize in abstractmediaitemview.cpp . The desktop icon size was too small, made it 128 right now, will be changed soon. Diffs (updated) - trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/abstractmediaitemview.cpp 046 trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/viewitem.cpp 046 Diff: http://reviewboard.kde.org/r/3494/diff Testing --- Works fine with the only shortcoming that icon size can't be set at runtime, due to existing structure. This will be fixed soon, but should not block this patch from going in. Thanks, Shantanu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Make the gridview behave correctly, no matter what icon size is set
On 2010-04-05 19:59:12, Alessandro Diaferia wrote: trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/abstractmediaitemview.cpp, line 56 http://reviewboard.kde.org/r/3494/diff/1/?file=22542#file22542line56 please, at least do this: setIconSize(KIconLoader::SizeEnormous); Cool, that worked nice ! On 2010-04-05 19:59:12, Alessandro Diaferia wrote: trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/viewitem.cpp, line 299 http://reviewboard.kde.org/r/3494/diff/1/?file=22543#file22543line299 I think we should have a static const int s_margin to define spacing between items if it is this what you want to achieve Ok, added ItemSpacing. This is in redundancy with ITEM_VERTICAL_MARGIN, which I will fix in the next patch as its related to the list view. - Shantanu --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3494/#review4883 --- On 2010-04-06 06:37:26, Shantanu Tushar Jha wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3494/ --- (Updated 2010-04-06 06:37:26) Review request for Plasma, Marco Martin and Alessandro Diaferia. Summary --- In the future, we need to support different sizes for previews. This patch adds preliminary support for this to happen. The size can be set in setIconSize in abstractmediaitemview.cpp . The desktop icon size was too small, made it 128 right now, will be changed soon. Diffs - trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/abstractmediaitemview.cpp 046 trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/viewitem.cpp 046 Diff: http://reviewboard.kde.org/r/3494/diff Testing --- Works fine with the only shortcoming that icon size can't be set at runtime, due to existing structure. This will be fixed soon, but should not block this patch from going in. Thanks, Shantanu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Make the gridview behave correctly, no matter what icon size is set
On 2010-04-05 19:59:12, Alessandro Diaferia wrote: I'm not 100% sure we should start with such an enormous size. I feel user preferences should be kept in high consideration, at least trying to find the biggest size among those specified by the user. In addition to this you can, and should IMHO, add the configuration option for this kind of setting inside the applet configuration interface. I'd like to know others opinions before giving a Ship It! :-) Oh, forgot to reply to this. Later we can add controls like zoom, or have a size calculated according to the user's screen size. To be able to do that, this patch fixes the grid view so that it can work with any size. - Shantanu --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3494/#review4883 --- On 2010-04-06 06:37:26, Shantanu Tushar Jha wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3494/ --- (Updated 2010-04-06 06:37:26) Review request for Plasma, Marco Martin and Alessandro Diaferia. Summary --- In the future, we need to support different sizes for previews. This patch adds preliminary support for this to happen. The size can be set in setIconSize in abstractmediaitemview.cpp . The desktop icon size was too small, made it 128 right now, will be changed soon. Diffs - trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/abstractmediaitemview.cpp 046 trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/viewitem.cpp 046 Diff: http://reviewboard.kde.org/r/3494/diff Testing --- Works fine with the only shortcoming that icon size can't be set at runtime, due to existing structure. This will be fixed soon, but should not block this patch from going in. Thanks, Shantanu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Subject: Re: Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web
-- Messaggio inoltrato -- From: Chani chan...@gmail.com To: plasma-devel@kde.org Date: Mon, 5 Apr 2010 15:52:07 -0700 Subject: Re: Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web On April 5, 2010 15:33:00 Diego Casella ([Po]lentino) wrote: Hi all, after reading some comments on my proposal, I've performed a couple of changes on the implementation details and the timeline, so it should fit better the GSoC schedule now :) To be more precise, I've also included improving PlasMate in order to show a widget to easily create and manage the private and public keys, along with the possibility to export the public keys. The Publish widget will be improved as well, showing a Sign checkbox that will allow the developer to choose which key, from the ones previously created, will be used to sign the plasmoid before the install/upload process. having plasmoid signing in plasmate is a good idea :) create and manage keys, though? that sounds like kgpg's job. I would imagine that plasmate would have something like kmail, where you can choose which key to use for signing, from your existing keys... although, you might want to add something that makes it easy for people not so familiar with gpg to get set up. so, hmm. That's exactly the reason :) Since plasmate is designed for lowering the bar for contribution to KDE, it means that almost certainly a tipical user won't be familiar with the concept of creating keys using kgpg. So that's why I'd like to provide a simplified widget for these operations. That's also the reason why I want to keep these keys separated between all the others because, if they aren't kept divided, the dev could delete the wrong entry by mistake, and this could be really bad. -- This message brought to you by eevil bananas and the number 3. www.chani3.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Make the gridview behave correctly, no matter what icon size is set
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3494/#review4887 --- trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/viewitem.cpp http://reviewboard.kde.org/r/3494/#comment4376 please call it ITEM_SPACING or s_itemSpacing so that we can immediately recognize it as a static const value :-) - Alessandro On 2010-04-06 06:37:26, Shantanu Tushar Jha wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3494/ --- (Updated 2010-04-06 06:37:26) Review request for Plasma, Marco Martin and Alessandro Diaferia. Summary --- In the future, we need to support different sizes for previews. This patch adds preliminary support for this to happen. The size can be set in setIconSize in abstractmediaitemview.cpp . The desktop icon size was too small, made it 128 right now, will be changed soon. Diffs - trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/abstractmediaitemview.cpp 046 trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/viewitem.cpp 046 Diff: http://reviewboard.kde.org/r/3494/diff Testing --- Works fine with the only shortcoming that icon size can't be set at runtime, due to existing structure. This will be fixed soon, but should not block this patch from going in. Thanks, Shantanu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dot article on activities needed, maybe more?
hey, On Sunday 04 April 2010 23:34:40 Aaron J. Seigo wrote: On April 4, 2010, Sebastian Kügler wrote: For Tokamak 4, I'm still looking for someone to write an article about the work on activities that has been done there. I've not followed these sessions myself, and I'm also having a hard time to wrap my head around the topic on mailing list discussions. That means that someone else has to write this article. as you already know, this one is on my plate. and i actually have time for it now that the javascript jam is all but wrapped up. i'll get it done in the next few days. I didn't know that, last time I asked you made clear to me that you were too busy, so my impression was that it remained on my plate. Glad to hear I misunderstood though, thanks for taking it on. Looking forward to reading the article, as an interested user. :) Also, please don't forget that by asking the KDE e.V. for sponsoring this event (which has been the most expensive (non-Akademy) developer meeting in its history so far) we agreed to properly report on what we're doing and what has been achieved during the meeting. to be perfectly frank, phrasing it in terms of KDE e.V. gives us more money, now you have to provide more documentatin on the other side is not the most useful way for the board to go about it. i also find it very distasteful how we are fairly constantly reminded how this was the most expensive meeting, as if we got away with something here or don't deserve it. this is especially galling as it isn't about deserving or not deserving at all. it's about investing where we think it's worthwhile to do so. i'd be completely fine if the board decided not to invest as much financial capital in Tokamak, and i've said so in previous emails. but when the board does put out that money, do not tie such strings to it. Well, we talked about this before Tokamak 4 with the board, and we agreed that so many things happen during such a sprint, that more than one post-sprint Dot story would be good to reflect that in the public perception. Initally, the idea was to do one article per subsprint, Plasma, KWin, Oxygen. I've changed this idea to do topical stories since that reflects much better how we work during Tokamak. KDE e.V. is not contracting out or investing in a third party. we are investing in ourselves. and the people we are investing in already give an amazing amount to the community and world at large through their efforts in KDE it would be good to treat it like that rather than use this is our (KDE e.V.'s) money, now you (contributors to KDE) earn it language. Maybe I didn't make this clear enough, but I really wrote this email as a Plasma team member asking fellow teammates for help, that's why I didn't CC: the board in the first place. If it came over like Board dude says: Plasma has to pay back the KDE e.V. with Dot stories, that at least wasn't my intention. I really don't think you need to tell me though how much contributors put into KDE, and how we cannot demand more. That feels ... backward given that I've invested muchos time in all of Plasma, Tokamak and KDE e.V.. Spreading the effort to make this whole system work is much needed. personally, i'd position it more as a here are the commitments we make to ourselves when use our resources to hold these events. this gives us a good way to measure our own progress, communicate our exciting developments to the outside world and reassure our investors that they are doing the right thing. this puts the us-them line outside of KDE (it's KDE and the public; KDE and our investors). the result is that it will create a lot less stress between people inside KDE since we will be working together on it, rather than trying to meet the expectations of our task masters. I agree I should've made the we do cool stuff, now let's also tell people who weren't there, but then it wasn't the first time I asked around, so to me, maybe a clearer I really need some help here, guys seemed more promising. yes, it's the same end result in either case, but these things actually do matter when trying to get people to do things in a timely manner with quality. putting pressure will also have the reverse effect desired here, i think. unless, of course, the desire is to do fewer and smaller KDE developer sprints in the future. (that's a valid goal, perhaps, depending on the budget expetations) Well, yes, but that's only indirectly related (no reporting - no justification for sponsor money - no sprints due to lack of funds). It's a consequence though, not a goal. as it stands, i've already personally decided that the next tokamak will be dramatically smaller. i said as much to kevin on one of the days at T4 when he and i went for a walk to discuss various matters related to KDE. a smaller even will be easier to manage, we won't have to go looking for resources that quite evidently are
Re: Dot article on activities needed, maybe more?
On Sunday 04 April 2010 23:50:57 Marco Martin wrote: On Sunday 04 April 2010, Sebastian Kügler wrote: Now the nice thing is that Tokamak 4 really was a blast, and that we've achieved a lot. And because of the size and variety of topics, I've decided to do the Tokamak 4 reporting on the Dot in a series of installments rather than in one big article. The work around hardware integration has already published (perhaps you've seen it on the Dot), an article about Plasma mobile is forthcoming (draft version on my disk, needs illustrating, links etc.). Then a friendly chap from kde-promo is still need something on the plasma mobile one? just ask :) can refine text make screenshots, photos/videos of the one device i still have... I think I've enough information about Plasma Mobile (from blogs, for example), but also because I was following it more closely. It's really the activity stuff I have no idea of. Which is why someone else is needed to chip in, I think it's a pretty important topic. Thanks for the offer though, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On Sunday 04 April 2010 23:30:38 Zack Rusin wrote: On Sunday 04 April 2010 15:48:32 Sebastian Kügler wrote: The amount of opportunities to tear your hair out in X.org land is near inifinite. Well, it's a lot like feeding a tiger - it's not that really difficult, it's just a bit dangerous especially if you try to stuff the food down the wrong hole. As you seemed to have been doing =) Nice analogy. :) displayconfig was actually written at a time when xrandr was rotate and resize, and nothing more than that. At least those bits worked, more or less reliably. Well, the resize at least. Often. :) It's worth to remember that X should be policy less, what and how it does should really be done higher. You never want to change the X config, especially nowadays when the there's really nothing there worth changing and it's not like hey, you've just started kpresenter, please restart X so that new output config can take be in effect is a good strategy anyway. The output config should be stored as part of the KDE config (Kephal I guess), and when I say output config I mean when an output with this identifier (and maybe even this exact edid) is connected we should do A where A is mirroring, setting up a new screen, doing nothing or doing whatever user picked the first time this action was performed. Once you know what you want to do, you simply use xrandr to actually do it. z That sounds sensible, yes. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ideas/Mockups for Mobile System Tray (GSoC)
On Monday 05 April 2010, 20:51 Alexis Ménard wrote: I just wonder where do you want to put the tiny version of the taskbar? Also I don't like (me) when thing pops magically from somewhere so i think when the big one appears it should be animated from the the tiny version (or at least have a visual hint that you expand the tiny version). +1 on this. Organic interfaces also implies that something comes from some place :) In nature, there is no such thing as things appearing and going away from nowhere (besides a fairy ;) ) 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
Review Request: Do not enable screensaver when it's switched off in the settings.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3501/ --- Review request for Plasma. Summary --- When entering full-screen mode in apps like Okular or Gwenview, the screensaver is disabled. It is always re-enabled when exiting full-screen, even if you have the screensaver disabled by default. This extra condition should take of this. This addresses bug 206475. https://bugs.kde.org/show_bug.cgi?id=206475 Diffs - /trunk/KDE/kdebase/workspace/krunner/screensaver/saverengine.cpp 661 Diff: http://reviewboard.kde.org/r/3501/diff Testing --- Thanks, Bram ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: add Open Image action to slideshow wallpaper context menu
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/#review4892 --- uhm, is it enough of an use case for the feature? or wouldn't the proper solution to make the wallpaper plugin to rotate the pictures accordingly to the exif tag? - Marco On 2010-04-06 02:59:03, Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/ --- (Updated 2010-04-06 02:59:03) Review request for Plasma, Aaron Seigo and Chani Armitage. Summary --- I use slideshow mode for my wallpaper and occasionally an image appears that needs to be rotated, but I don't know where the file is. I added a context action to slideshow wallpaper that will open the current image in the image app the user has configured (gwenview by default I believe) so it can then be rotated/fixed whatever. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1109045 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1109045 Diff: http://reviewboard.kde.org/r/3498/diff Testing --- I tested it on my machine that has trunk built and it seems to work fine. Thanks, Jeremy ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Do not enable screensaver when it's switched off in the settings.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3501/#review4893 --- Ship it! good catch - Marco On 2010-04-06 13:34:50, Bram Schoenmakers wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3501/ --- (Updated 2010-04-06 13:34:50) Review request for Plasma. Summary --- When entering full-screen mode in apps like Okular or Gwenview, the screensaver is disabled. It is always re-enabled when exiting full-screen, even if you have the screensaver disabled by default. This extra condition should take of this. This addresses bug 206475. https://bugs.kde.org/show_bug.cgi?id=206475 Diffs - /trunk/KDE/kdebase/workspace/krunner/screensaver/saverengine.cpp 661 Diff: http://reviewboard.kde.org/r/3501/diff Testing --- Thanks, Bram ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC : Multiscreen management
On April 5, 2010, Will Stephenson wrote: The output config should be stored as part of the KDE config (Kephal I guess) +1, and this is where KDE really falls behind the competition now that fewer Xorgs have fixed configuration files, and we don't have store/restorable X configuration in the user session. hopefully this is already being taken into consideration, but just in case: one thing to keep in mind here is ensuring that x.org is set up asap when the desktop is started. we have had a number of bug reports related to issues that occur when the user logs in and x.org changes resolutions after the desktop is loaded. plasma-desktop tends to do just fine in these cases now-a-days, but it does add time and computation to the start up sequence. it would be great if we can guarantee that x.org is fully configured before plasma-desktop starts. if that means kicking off that configuration in plasma- desktop itself, so be it, but i'd personally prefer to see a separate process that is guaranteed to run first in the log in process (otherwise we end up duplicating this code in all the shells; though we do have libplasmagenericshell for that as well i suppose..) -- 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
Re: Akonadi Calendar Dataengine
Hi all, I landed a first version of the data engine in playground now (it's a copy of the calendar one). Please let me know if it works for you - it should automatically start akonadi, but unless you have something in your akonadi calendar, it won't work. And it should work with KDE 4.4 afaict. It's compatible with the old calendar one, so just install it and you shouldn't notice a change. Requests to it have to have the form: calendar:-mm-dd:-mm-dd where the two dates are a range. Currently you might get some events that are not in the range due to things like recurrence making it not easy to correctly filter in some cases. I'd be happy if anyone would write a quick calendar list plasmoid as example, it could simply show a list of dates and the corresponding event. Greetings, Frederik Aaron J. Seigo wrote: On April 5, 2010, Frederik Gladhorn wrote: Calendar - this one uses queries like isHoliday:region:date and gives i think this is the one that should be extended. it was always the intention to do so, in fact. :) For my purpose I'd rather use a date range to query calendar events. So I'd suggest parameters like: * start date (maybe like the current Calendar engine - iso: -mm-dd) * end date * optional a filter for types - this can be one of: event/todo/journal - is this useful? Returned would be maps with: start date-time, end date-time, summary, long description, location and type sounds good. Is anyone up to changing the current calendar? It would need at least more sure; i know that code reasonably well (not the original author, however :) and it should be very easy to do. Let me know if this is desirable, which data engine to change and then I'm hoping for cool new todo list plasmoids and an extended calendar for the clock for TODOs, see the todo runner in kdereview. Next step would of course be adding a service as well in order to add new calendar events. yep; DataEngine::serviceForSource ftw :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Feedback wanted: Improvements to current Qt Widget/style mechanism
Hello! We had some talks about this during Tokamak3 (in Switzerland) and we collected the feedback, thought about some solutions and came up with this proposal. It's also important to say that we want to do everything related to this subject as open as possible and that's why we're including you since the beginning of the discussions :) So please, give us some feedback and help us improve the state of the art of Qt's widgets/styles. Hi, We are writing to get some feedback from you in the context of a proposal to improve current widget/style mechanism of Qt. We would like to ask you to read this and provide feedback, in particular by answering the last three questions. Keep in mind that all of this is work in progress, and even though we wrote some experimental code, there's nothing written in stone. == Reason == Developers that want to customize the UI and/or behavior of existing Qt widgets (QWidgets or QGraphicsWidgets) are not able to do that with QStyle, or don't want to, either because it uses an outdated procedural painting approach or because it is not flexible enough. As a result, many people writing rich UIs are writing their own widgets instead of using those available in Qt. However this process is time-consuming and leads to the creation of code that is duplicated and prone to bugs. The Qt Components project was born to provide a better solution for those willing to customize the look and feel of C++ widgets as well as to provide an easier way for Qt Quick developers to handle the boilerplate code of their UI. == Proposed solution == Our proposed solution has the two following parts: -- Models -- The first is a set of UI-independent models (back-ends) that will hold the boilerplate logic currently found inside the technology-specific widgets (QPushButton, QSlider, etc) What we want to solve here is the separation between what is: - look and feel: How does this button respond to a hover event? What is the click area of it? Is this slider shown as a bar or a twisting knob? - state and logic: The mouse went out and in the mouse area, is that a click? This button is inside a mutual exclusivity group, which button should I uncheck when this one is checked? The benefit is that Qt Quick designers can use this button backend to handle the developer-oriented logic and focus on what matters, UI. Also, if we have widgets implemented as QWidgets for instance, it becomes easy to implement their QGraphicsWidget or QDeclarativeItem counterparts, without duplicating the code. -- Style -- The second is a new styling mechanism that is flexible enough for rich UI applications to use and that fits the existing technologies as well as the upcoming ones. The main reason for creating a new style system in Qt is to use a primitive-graph approach over the existing procedural painting. That means the style will be responsible for hooking a group of primitives (image, text, rectangle) in the about-to-be-styled widget, rather than actually painting parts of it. That way we have more flexibility over how to style the widget, and it becomes easier for the canvas to automatically cache painted primitives. We came up with an architecture that uses the following concepts, that are somehow independent and that we would like to hear feedback about. a) Style::populate(Widget, Model = 0) method Style classes provide a populate method that is called by styleable widgets upon their construction. The arguments are the widget itself, it will be the parent of the primitives created by the style, and the optional model (backend) used by this widget. Example: When populating a Button the style creates two background primitives (one for pressed, one for released) and one text primitive for the button label. That probably looks fine, but raises a question, what would happen when the button label changes? How would the primitive be updated? The same holds for a button press, how would the background primitive know about that? We do not intend to create an updatePrimitives method or something that would require the widget state information to flow through the style. Neither we wanted the Button to assume/expect anything about the primitives it has. To keep that decoupled, we would rather use the data binding concept from Qt Quick. That means when the style populates the button for the first time it would create a binding between the label property exported by the button and the text property of the text primitive. For the background, it would bind the pressed property from the button model to the visible property of the pressed background primitive. Once again, the idea is to use a more designer-friendly concept and reduce the style API to a
Review Request: Change the way dbus and fdo tasks are destroyed
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3505/ --- Review request for Plasma, Aaron Seigo and Marco Martin. Summary --- Try to make dbus and fdo tasks have the same life cycle. Now the Manager class is responsible for calling deleteLater. Make DBus tasks emits only once the destroyed signal. Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/manager.cpp 1110082 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/task.cpp 1110082 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp 1110298 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.cpp 1110082 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 1110082 Diff: http://reviewboard.kde.org/r/3505/diff Testing --- Tested with dbus and fdo tasks inside a kde 4.4.2 session and Qt 4.6.2. Nothing crash. Thanks, Matthieu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ToolTip regression?
On Tue, Apr 6, 2010 at 12:00 PM, Aaron J. Seigo ase...@kde.org wrote: Plasma::TreeView is just a thin wrapper around a QGraphicsProxyWidget containing a QTreeView. can you try to replicate the problem by replacing Plasma::TreeView in your Plasmoid with a QGraphicsProxyWidget and a QTreeView directly? or, even better, a simple test case that is qt-only with a QGraphicsProxyWidget-QTreeView combination on a QGraphicScene? I have already tried a native QTreeView inside a dialog, and that works fine. I will try a QGraphicsProxyWidget. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
On April 6, 2010, Frederik Gladhorn wrote: Requests to it have to have the form: calendar:-mm-dd:-mm-dd where the two dates are a range. could we replace calendar: with events:? another concern is that if you have two calendars viewing similar data, the data won't get shared. e.g. if one calendar is viewing march and the other one april, it would be nice if the DataEngine would not duplicate the dates on each side of march and april (to show spill over between the two months). would it be possible instead (additionally?) to support: events:2010:week50 this would mean the calendar would have to request 6 sources instead of 1 in many cases, but it would ensure the data is shared as much as possible. it would also mean that when switching from march to april, only 4 weeks of data would need to be fetched instead of 6. I'd be happy if anyone would write a quick calendar list plasmoid as example, it could simply show a list of dates and the corresponding event. i'd rather just plug it right into the actual calendar. it's not hard. let's work out the above details and then i'll work on adding it to the clock calendar. -- 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
Re: Review Request: add Open Image action to slideshow wallpaper context menu
On 2010-04-06 14:31:17, Marco Martin wrote: uhm, is it enough of an use case for the feature? or wouldn't the proper solution to make the wallpaper plugin to rotate the pictures accordingly to the exif tag? Hmm, others (maybe even me once I learn how) might also want to use it to get rid of redeye, crop images, and other stuff too. That was just my immediate use case is all. What do you think? - Jeremy --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/#review4892 --- On 2010-04-06 02:59:03, Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/ --- (Updated 2010-04-06 02:59:03) Review request for Plasma, Aaron Seigo and Chani Armitage. Summary --- I use slideshow mode for my wallpaper and occasionally an image appears that needs to be rotated, but I don't know where the file is. I added a context action to slideshow wallpaper that will open the current image in the image app the user has configured (gwenview by default I believe) so it can then be rotated/fixed whatever. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1109045 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1109045 Diff: http://reviewboard.kde.org/r/3498/diff Testing --- I tested it on my machine that has trunk built and it seems to work fine. Thanks, Jeremy ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: add Open Image action to slideshow wallpaper context menu
On 2010-04-06 14:31:17, Marco Martin wrote: uhm, is it enough of an use case for the feature? or wouldn't the proper solution to make the wallpaper plugin to rotate the pictures accordingly to the exif tag? Jeremy Whiting wrote: Hmm, others (maybe even me once I learn how) might also want to use it to get rid of redeye, crop images, and other stuff too. That was just my immediate use case is all. What do you think? yes, makes sense - Marco --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/#review4892 --- On 2010-04-06 02:59:03, Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/ --- (Updated 2010-04-06 02:59:03) Review request for Plasma, Aaron Seigo and Chani Armitage. Summary --- I use slideshow mode for my wallpaper and occasionally an image appears that needs to be rotated, but I don't know where the file is. I added a context action to slideshow wallpaper that will open the current image in the image app the user has configured (gwenview by default I believe) so it can then be rotated/fixed whatever. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1109045 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1109045 Diff: http://reviewboard.kde.org/r/3498/diff Testing --- I tested it on my machine that has trunk built and it seems to work fine. Thanks, Jeremy ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: add Open Image action to slideshow wallpaper context menu
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/#review4896 --- Ship it! - Marco On 2010-04-06 02:59:03, Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/ --- (Updated 2010-04-06 02:59:03) Review request for Plasma, Aaron Seigo and Chani Armitage. Summary --- I use slideshow mode for my wallpaper and occasionally an image appears that needs to be rotated, but I don't know where the file is. I added a context action to slideshow wallpaper that will open the current image in the image app the user has configured (gwenview by default I believe) so it can then be rotated/fixed whatever. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1109045 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1109045 Diff: http://reviewboard.kde.org/r/3498/diff Testing --- I tested it on my machine that has trunk built and it seems to work fine. Thanks, Jeremy ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Feedback wanted: Improvements to current Qt Widget/style mechanism
On April 6, 2010, Artur Souza (MoRpHeUz) wrote: We came up with an architecture that uses the following concepts, that are somehow independent and that we would like to hear feedback about. each sound more or less plausible, but what are the functional requirements for this system? reading the various proposed methods and reverse engineering them, it seems that list is something like: * decouple logic from presentation * scoping, so the logic and/or presentation associated with a widget can be changed on the fly in an app depending on the scope (case given in your email was main UI versus a config dialog) * designer friendly * ability to do CSS styling for QtWebkit (hooray for *proper* native widgets in QtWebkit!) what i didn't see was anything about animaton / state transition requirements and what isn't in scope (e.g. feed starving children, improve Qt's model/view painting with delegates). if you can provide some more insights into the above, then i can probably provide something closer to useful input in return :) -- 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
Re: [GSoC Proposal] Plasma widget sharing using telepathy
On April 6, 2010, Daniele E. Domenichelli wrote: Plasma already allows to share widgets on the local network using avahi/zeroconf. I think that a cool feature could be to use StreamTubes to allow the widget to be shared with your contacts using your favourite im protocol. That should not be hard, because StreamTubes allow to reuse the existing protocol using telepathy to transport it. What do you think about it? +1 from me. this would give us a nice excuse to make some of the hard coded dependencies on zeroconf more flexible. -- 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
Re: ToolTip regression?
On Tue, Apr 6, 2010 at 12:48 PM, Rob Hasselbaum r...@hasselbaum.net wrote: On Tue, Apr 6, 2010 at 12:00 PM, Aaron J. Seigo ase...@kde.org wrote: Plasma::TreeView is just a thin wrapper around a QGraphicsProxyWidget containing a QTreeView. can you try to replicate the problem by replacing Plasma::TreeView in your Plasmoid with a QGraphicsProxyWidget and a QTreeView directly? or, even better, a simple test case that is qt-only with a QGraphicsProxyWidget-QTreeView combination on a QGraphicScene? I have already tried a native QTreeView inside a dialog, and that works fine. I will try a QGraphicsProxyWidget. Same problem exists with a QGraphicsProxyWidget in a standalone QGraphicsView, so I guess this is a Qt bug. Thanks. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
Aaron J. Seigo wrote: On April 6, 2010, Frederik Gladhorn wrote: Requests to it have to have the form: calendar:-mm-dd:-mm-dd where the two dates are a range. could we replace calendar: with events:? sounds good to me (done) another concern is that if you have two calendars viewing similar data, the data won't get shared. e.g. if one calendar is viewing march and the other one april, it would be nice if the DataEngine would not duplicate the dates on each side of march and april (to show spill over between the two months). would it be possible instead (additionally?) to support: events:2010:week50 this would mean the calendar would have to request 6 sources instead of 1 in many cases, but it would ensure the data is shared as much as possible. it would also mean that when switching from march to april, only 4 weeks of data would need to be fetched instead of 6. Yes, we just need to decide on a good format. Internally it uses models that akonadi supplies and the filtering is done by using a proxy model, so we're quite flexible. If possible I'd like to use some values that KDateTime can easily use, so that no special date parsing is needed. I imagine weeks feel awkward to work with, so how about just using months? That is what the holiday calendar currently does. Calculating which week a certain date corresponds to is not difficult but I bet it leads to confusion somewhere. The holiday syntax looks like this: holidaysInMonth:de:2010-04-01 where you can in fact put in anything for the day value and you'll get back the holiday dates for the month. So would eventsInMonth:2010-04-01 sound OK? I don't have strong feelings about this. Also is there some way to know when a data source is no longer needed? Or does that only happen when the data engine is deleted? I'd be happy if anyone would write a quick calendar list plasmoid as example, it could simply show a list of dates and the corresponding event. i'd rather just plug it right into the actual calendar. it's not hard. let's work out the above details and then i'll work on adding it to the clock calendar. I still think a plasma-akonadi-todo list would be easy to write and nice to have (I'm not overly fond of the plasma calendar looks). Cheers Frederik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
GSoC 2010 proposal
Hi I would like to work on 'Grid and grouping containments' for GSoC 2010. My proposal is here: http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/sarathkrishna/t127050766223 Could you please review my proposal, so I can improve my proposal. If there is any mistake please correct me. thanks in advance -- Sarath ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change the way dbus and fdo tasks are destroyed
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3505/#review4897
---
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp
http://reviewboard.kde.org/r/3505/#comment4377
afaict from reading the code, this is the line that is incorrect. this
patch just works around that fact.
my guess is that this was done this way because deleteLater() schedules the
deletion for the next trip through the event loop.
what's probably needed here is a new method in Task that does this:
void Task::destroy()
{
emit destroyed(this);
deleteLater();
}
then make the destructor of Task private to ensure that all deletions must
be replaced with cals to destroy().
- Aaron
On 2010-04-06 16:49:20, Matthieu Gallien wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3505/
---
(Updated 2010-04-06 16:49:20)
Review request for Plasma, Aaron Seigo and Marco Martin.
Summary
---
Try to make dbus and fdo tasks have the same life cycle. Now the Manager
class is responsible for calling deleteLater. Make DBus tasks emits only once
the destroyed signal.
Diffs
-
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/manager.cpp
1110082
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/task.cpp
1110082
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp
1110298
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.cpp
1110082
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdotask.h
1110082
Diff: http://reviewboard.kde.org/r/3505/diff
Testing
---
Tested with dbus and fdo tasks inside a kde 4.4.2 session and Qt 4.6.2.
Nothing crash.
Thanks,
Matthieu
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: add Open Image action to slideshow wallpaper context menu
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/ --- (Updated 2010-04-06 17:40:53.755197) Review request for Plasma and Chani Armitage. Summary --- I use slideshow mode for my wallpaper and occasionally an image appears that needs to be rotated, but I don't know where the file is. I added a context action to slideshow wallpaper that will open the current image in the image app the user has configured (gwenview by default I believe) so it can then be rotated/fixed whatever. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1109045 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1109045 Diff: http://reviewboard.kde.org/r/3498/diff Testing --- I tested it on my machine that has trunk built and it seems to work fine. Thanks, Jeremy ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: add Open Image action to slideshow wallpaper context menu
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/#review4898 --- Ship it! it's good for me, with one small change to the user visible text. bonus points for the fixes to the coding style. :) trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp http://reviewboard.kde.org/r/3498/#comment4378 for consistency with the above action, it sould probably be Open Wallpaper Image. - Aaron On 2010-04-06 17:40:53, Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3498/ --- (Updated 2010-04-06 17:40:53) Review request for Plasma and Chani Armitage. Summary --- I use slideshow mode for my wallpaper and occasionally an image appears that needs to be rotated, but I don't know where the file is. I added a context action to slideshow wallpaper that will open the current image in the image app the user has configured (gwenview by default I believe) so it can then be rotated/fixed whatever. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1109045 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1109045 Diff: http://reviewboard.kde.org/r/3498/diff Testing --- I tested it on my machine that has trunk built and it seems to work fine. Thanks, Jeremy ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
On April 6, 2010, Frederik Gladhorn wrote: So would eventsInMonth:2010-04-01 sound OK? I don't have strong feelings about this. yes, that'd be cool as well, and keep it consistent with holidays. events:2010-04-02 could then return the events for just one day? would that make sense? Also is there some way to know when a data source is no longer needed? Or does that only happen when the data engine is deleted? even better, it happens automatically when the source is no longer connected to any visualization. -- 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
Re: Feedback wanted: Improvements to current Qt Widget/style mechanism
On Tuesday 06 April 2010, Artur Souza (MoRpHeUz) wrote: Hello! We had some talks about this during Tokamak3 (in Switzerland) and we collected the feedback, thought about some solutions and came up with this proposal. It's also important to say that we want to do everything related to this subject as open as possible and that's why we're including you since the beginning of the discussions :) So please, give us some feedback and help us improve the state of the art of Qt's widgets/styles. Hi, We are writing to get some feedback from you in the context of a proposal to improve current widget/style mechanism of Qt. We would like to ask you to read this and provide feedback, in particular by answering the last three questions. Keep in mind that all of this is work in progress, and even though we wrote some experimental code, there's nothing written in stone. == Reason == Developers that want to customize the UI and/or behavior of existing Qt widgets (QWidgets or QGraphicsWidgets) are not able to do that with QStyle, or don't want to, either because it uses an outdated procedural painting approach or because it is not flexible enough. As a result, many people writing rich UIs are writing their own widgets instead of using those available in Qt. However this process is time-consuming and leads to the creation of code that is duplicated and prone to bugs. this actually happens for two reasons: to change the look is one, but i have more often seen it done purely to enhance functinality, so what would have needed to be changed is the model side. any solution should allow both use cases. so, to do a simple example let's say that the default pushbutton model doesn't allow to have a menu on press (i know it will, just an example) so, in order to have a pushbutton with menu i have to: a) subclass the pushbutton model, to add the menu manipulation into it b) subclass the visualization to let's say add an arrow that indicates it expands. The Qt Components project was born to provide a better solution for those willing to customize the look and feel of C++ widgets as well as to provide an easier way for Qt Quick developers to handle the boilerplate code of their UI. == Proposed solution == Our proposed solution has the two following parts: -- Models -- The first is a set of UI-independent models (back-ends) that will hold the boilerplate logic currently found inside the technology-specific widgets (QPushButton, QSlider, etc) What we want to solve here is the separation between what is: - look and feel: How does this button respond to a hover event? What is the click area of it? Is this slider shown as a bar or a twisting knob? - state and logic: The mouse went out and in the mouse area, is that a click? This button is inside a mutual exclusivity group, which button should I uncheck when this one is checked? The benefit is that Qt Quick designers can use this button backend to handle the developer-oriented logic and focus on what matters, UI. Also, if we have widgets implemented as QWidgets for instance, it becomes easy to implement their QGraphicsWidget or QDeclarativeItem counterparts, without duplicating the code. on one hand, i feel in order to succeed the normal qwidgets need to use this (so until qt5 their api would be a mis of model and view related stuff), but this brings to the question: what about subclasses of qwidgets that subclassed it for functionality? (i.e. kpushbutton) -- Style -- The second is a new styling mechanism that is flexible enough for rich UI applications to use and that fits the existing technologies as well as the upcoming ones. The main reason for creating a new style system in Qt is to use a primitive-graph approach over the existing procedural painting. That means the style will be responsible for hooking a group of primitives (image, text, rectangle) in the about-to-be-styled widget, rather than actually painting parts of it. That way we have more flexibility over how to style the widget, and it becomes easier for the canvas to automatically cache painted primitives. yeah, this is a good thing We came up with an architecture that uses the following concepts, that are somehow independent and that we would like to hear feedback about. a) Style::populate(Widget, Model = 0) method Style classes provide a populate method that is called by styleable widgets upon their construction. The arguments are the widget itself, it will be the parent of the primitives created by the style, and the optional model (backend) used by this widget. uh, so would be the primitive qobjects? Example: When populating a Button the style creates two background
Re: GSoC 2010 proposal
On April 6, 2010, sarath krishna wrote: Hi I would like to work on 'Grid and grouping containments' for GSoC 2010. My proposal is here: http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/sa rathkrishna/t127050766223 it looks pretty good already. the two open questions here for me are: * is an arrange in a grid feature more or less useful than making it easy to snap widgets during resize and move to the edges of other widgets? arranging widgets in a grid for the user will lead to interesting and possibly intractible challenges like how wide/tall should the colums/rows be? * right now each containment implements its own layout strategy and that's actually quite useful (c.f. newspaper vs panel vs desktop). however, in some cases (desktop and folderview) it would be nice to share layout strategies. this might be a nice addition. -- 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
Re: Akonadi Calendar Dataengine
Hi, Aaron J. Seigo wrote: On April 6, 2010, Frederik Gladhorn wrote: So would eventsInMonth:2010-04-01 sound OK? I don't have strong feelings about this. yes, that'd be cool as well, and keep it consistent with holidays. events:2010-04-02 could then return the events for just one day? would that make sense? Sure, no problem. I'll finish that tonight. Also is there some way to know when a data source is no longer needed? Or does that only happen when the data engine is deleted? even better, it happens automatically when the source is no longer connected to any visualization. My question was for the individual requests within one engine. But even more important: What if I get a second sourceRequestEvent() for the same source string? Do I have to call setData() again or will the old values be returned from cache without my intervention? Cheers Frederik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
On April 6, 2010, Frederik Gladhorn wrote: What if I get a second sourceRequestEvent() for the same source string? Do if the source already exists, it won't get called again. sourceRequestEvent is *only* called when the source does not exist. once it exists, calls are made to updateSourEvent as needed (e.g. due to a connected visualization requesting a polling interval when calling connectSource). the DataEngine may also decide to update the source on its own. there are a few issues i see in the current code in playground: a) eventData[StartDate] = model-index(row, Akonadi::CalendarModel::DateTimeStart).data().toDateTime().toString(); that last toString() probably isn't needed. puting the QDateTime object in there is just fine. b) this is in akonadiCalendarSourceRequest, but it should be in initAkonadiCalendar (to avoid multiple connections): connect(m_calendarModel, SIGNAL(rowsInserted(QModelIndex, int , int )), this, SLOT(calendarModelRowsInserted(QModelIndex,int,int))); c) when a source is requested, akonadiCalendarSourceRequest is called. this creates a new Akonadi::DateRangeFilterProxyModel and that remains around for the lifetime of the engine. what i'd recommend here is creating a subclass of Plasma::DataContainer that has the Akonadi::DateRangeFilterProxyModel as a member. then in sourceRequetEvent, the engine could just do something like: initAkonadiCalendar(); addSource(new AkonadiDateRangeSource(name, start, end)); return true; this hypothetical AkonadiDateRangeSource class would subclass Plasma::DataContainer, call setObjectName(name) in its constructor, connect the signals to itself which call setData() on itself as appropriate and then setNeedsUpdate() (which schedules the signals for the visualizations that are connected). this way, when the source goes out of use (e.g. all the visualizations disconnect from it) then the Akonadi::DateRangeFilterProxyModel would also get deleted. it would also move all of the Akonadi code related to the events date ranges out into its own class (nice for code clarity) -- 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
Re: Review Request: Change the way dbus and fdo tasks are destroyed
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3505/ --- (Updated 2010-04-06 19:45:35.640069) Review request for Plasma, Aaron Seigo and Marco Martin. Changes --- Implement the suggested change by Aaron. I had to make the destructor of Task protected in order to be able to call destructors of the derived classes. Summary --- Try to make dbus and fdo tasks have the same life cycle. Now the Manager class is responsible for calling deleteLater. Make DBus tasks emits only once the destroyed signal. Diffs (updated) - /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/task.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 824 Diff: http://reviewboard.kde.org/r/3505/diff Testing --- Tested with dbus and fdo tasks inside a kde 4.4.2 session and Qt 4.6.2. Nothing crash. Thanks, Matthieu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change the way dbus and fdo tasks are destroyed
On 2010-04-06 17:34:33, Aaron Seigo wrote:
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp,
line 92
http://reviewboard.kde.org/r/3505/diff/2/?file=22631#file22631line92
afaict from reading the code, this is the line that is incorrect. this
patch just works around that fact.
my guess is that this was done this way because deleteLater() schedules
the deletion for the next trip through the event loop.
what's probably needed here is a new method in Task that does this:
void Task::destroy()
{
emit destroyed(this);
deleteLater();
}
then make the destructor of Task private to ensure that all deletions
must be replaced with cals to destroy().
I did the changes you suggested but I do not really understand what you mean.
What was causing me troubles is that if I was waiting for the signal emission
fro the Task destructor, then I get crashes in the Manager::removeTask method.
Does your suggestion is referring to this ?
- Matthieu
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3505/#review4897
---
On 2010-04-06 19:45:35, Matthieu Gallien wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3505/
---
(Updated 2010-04-06 19:45:35)
Review request for Plasma, Aaron Seigo and Marco Martin.
Summary
---
Try to make dbus and fdo tasks have the same life cycle. Now the Manager
class is responsible for calling deleteLater. Make DBus tasks emits only once
the destroyed signal.
Diffs
-
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/task.cpp
824
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp
824
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.cpp
824
/trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdotask.h
824
Diff: http://reviewboard.kde.org/r/3505/diff
Testing
---
Tested with dbus and fdo tasks inside a kde 4.4.2 session and Qt 4.6.2.
Nothing crash.
Thanks,
Matthieu
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change the way dbus and fdo tasks are destroyed
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3505/ --- (Updated 2010-04-06 20:13:24.362369) Review request for Plasma, Aaron Seigo and Marco Martin. Changes --- More complete patch than the previous one. Change all the code including plasmoid protocol to use the new slot destroy in Task class. I tested the addition and removal of fdo visible and hidden tasks. I tested the addition and removal of dbus visible and hidden tasks. My testing does not trigger any problem. Summary --- Try to make dbus and fdo tasks have the same life cycle. Now the Manager class is responsible for calling deleteLater. Make DBus tasks emits only once the destroyed signal. Diffs (updated) - /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/task.h 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/task.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/core/task.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp 824 /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtaskprotocol.cpp 824 Diff: http://reviewboard.kde.org/r/3505/diff Testing --- Tested with dbus and fdo tasks inside a kde 4.4.2 session and Qt 4.6.2. Nothing crash. Thanks, Matthieu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: global menu bar for gsoc
On Sunday 04 April 2010 22:17:23 Aaron J. Seigo wrote:
On April 4, 2010, Ivan Ruchkin wrote:
Why can't we just take the dbus client-server mechanism from Bespin and
XBar? Menubar containment will serve as server and every application as a
client.
that's certainly a possibility. always nice to avoid reinventing the wheel.
i haven't looked at how Bespin does it exactly, yet, so have to reserve
some judgement.
Since this topic is currently discussed I think it makes sense to share a
patch that extracts the client side of bespin and applies to the oxygen
kstyle. As I'm a user of the global menubar but like oxygen better than bespin
I have made this patch some time ago and I'm using it without major problems.
Maybe it will save you some time looking at how the bespin model works. (Note:
this is just the client side. You still need the X-Bar plasmoid from bespin)
I might add that there is another problem to think of. Some applications like
KDevelop or rekonq modify the menu bar. Perhaps it would make sense to think
also at those cases while making a decision how to design the global menu bar.
Cheers,
Michael
Index: kstyles/oxygen/oxygen.cpp
===
--- kstyles/oxygen/oxygen.cpp (revision 1072273)
+++ kstyles/oxygen/oxygen.cpp (working copy)
@@ -30,7 +30,10 @@
*/
#include oxygen.h
+#include macmenu.h
#include oxygen.moc
+#include macmenu.moc
+#include macmenu-dbus.moc
#include QtGui/QAbstractItemView
#include QtGui/QApplication
@@ -3235,6 +3238,11 @@
if (qobject_castQMenuBar*(widget))
{
+kDebug() ** Checking App: QCoreApplication::applicationName();
+if(!((Designer==QCoreApplication::applicationName() || kdevelop==QCoreApplication::applicationName()) widget-inherits(QDesignerMenuBar))) {
+kDebug() applying MacMenu;
+Bespin::MacMenu::manage((QMenuBar *)widget);
+}
widget-setBackgroundRole(QPalette::NoRole);
@@ -3340,8 +3348,11 @@
|| qobject_castQLineEdit*(widget)
) { widget-setAttribute(Qt::WA_Hover, false); }
-if (qobject_castQMenuBar*(widget)
-|| (widget widget-inherits(Q3ToolBar))
+if (qobject_castQMenuBar*(widget)) {
+Bespin::MacMenu::release((QMenuBar *)widget);
+}
+
+if (widget widget-inherits(Q3ToolBar)
|| qobject_castQToolBar*(widget)
|| (widget qobject_castQToolBar *(widget-parent()))
|| qobject_castQToolBox*(widget))
@@ -4977,6 +4988,19 @@
}
+case SH_MainWindow_SpaceBelowMenuBar:
+{
+//if(opts.xbar)
+if (const QMenuBar *menubar = qobject_castconst QMenuBar*(widget))
+if (0==menubar-height() !menubar-actions().isEmpty())
+{ // we trick menubars if we use macmenus - hehehe...
+// NOTICE the final result NEEDS to be 0 (i.e. 1) to avoid side effects...
+return -menubar-actionGeometry(menubar-actions().first()).height() + 1;
+}
+
+return 0;
+}
+
case SH_Menu_Mask:
{
Index: kstyles/oxygen/macmenu.cpp
===
--- kstyles/oxygen/macmenu.cpp (revision 0)
+++ kstyles/oxygen/macmenu.cpp (revision 0)
@@ -0,0 +1,487 @@
+/* Bespin mac-a-like XBar KDE4
+Copyright (C) 2007 Thomas Luebking thomas.luebk...@web.de
+
+This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Library General Public
+License version 2 as published by the Free Software Foundation.
+
+This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Library General Public License for more details.
+
+ You should have received a copy of the GNU Library General Public License
+ along with this library; see the file COPYING.LIB. If not, write to
+ the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ Boston, MA 02110-1301, USA.
+ */
+
+#include QActionEvent
+#include QApplication
+#include QtDBus/QDBusInterface
+#include QtDBus/QDBusConnectionInterface
+#include QLayout
+#include QMenuBar
+#include QWindowStateChangeEvent
+
+#include macmenu.h
+#include macmenu-dbus.h
+
+#include QtDebug
+
+using namespace Bespin;
+
+static MacMenu *instance = 0;
+static QDBusInterface *xbar = 0;
+
+bool
+FullscreenWatcher::eventFilter(QObject *o, QEvent *ev)
+{
+QWidget *window = qobject_castQWidget*(o);
+if (!(window ev-type() == QEvent::WindowStateChange))
+return false;
+if (window-windowState() Qt::WindowFullScreen)
+instance-deactivate(window);
+else
+instance-activate(window);
+return false;
+}
+
+static FullscreenWatcher
Re: global menu bar for gsoc
On Tuesday 06 April 2010, Michael Zanetti wrote: I might add that there is another problem to think of. Some applications like KDevelop or rekonq modify the menu bar. Perhaps it would make sense to think also at those cases while making a decision how to design the global menu bar. with rekonq no problem, you just have an empty menubar but all the useful menu items are still there in the rekonq menu. the problem is kdevelop that adds things that you would lose (the little tabbar) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: [Quicklaunch] Refactoring, layout fixes and a drag drop marker.
Lukas Appelhans wrote: Am Montag 05 April 2010 17:00:29 schrieb Ingomar Wesp: This suggestion would remove the need (and the ability) to set the icon size altogether. We would have to define some default row height at which wrapping takes place, but the user would be able to override it by setting force number of rows... Please tell me what you think. Well go for it I think :) It's good to have some standard behaviour for certain things which we should follow at least in the applets which are shipped by default... Thanks for the encouragement. Then I'll go for it :) Would you recommend that I commit the submitted patch and implement the changes on top of that or should I rather create one mega-patch that includes all the changes we discussed so far? So long, Ingomar ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Feedback wanted: Improvements to current Qt Widget/style mechanism
Hello Aaron, each sound more or less plausible, but what are the functional requirements for this system? If we had to say _one_ problem that we want to solve, in a very informal way, that would be: Avoid the need of every new Qt-based framework/library in town to reimplement a widget and style infrastructure In particular every new project on top of QGraphicsView had to deal with that, we at INdT had a couple of those projects internally, and publicly we have libdui, UI Extensions for Mobile (aka Orbit) and the Plasma widget set. Even with QML at hand, we understand there's a demand for avoid doing stuff again and again. For example, reimplementing the logic of a scrollbar in QML is clearly possible, but in practice, you don't want to deal with that when developing applications. We think that providing the right set of tools, much of this rework and implementations of basic widget infrastructure could be avoided. In this context, some points we think are important in order to reach this goal: 1) Decoupling logic from presentation. Marius presented the core of this idea Bossa Conference this year (slides: http://www.slideshare.net/mariusbu/the-future-of-qt-widgets). With this model idea for example, it would be possible to have a class with all the information needed to make a pushbutton, that KDE would extend it and could share between Plasma::PushButton and KPushButton for instance. This would avoid having a KPushButton inside a Plasma::PushButton just to use it's logic and change the view of the widget. 2) Allow the subgraph approach instead of procedural painting As said in the email, existing QStyle does not fit for that job. 3) More extensible style system A Style system that enables us to take care of WebKit requirements is a big win, making the life easier for QtWebKit simply use the platform style and fallback to a FullCSSStyle if necessary (if the page CSS demands that). A Style system that enables using QML to describe the interface of our widgets (and even use this style in a C++ program). And that enable QML to use QDeclarativeItems that are styled in C++, what people call using native/platform style in QML. This relates to our core problem. QStyle wasn't enough for requirements of Orbit and libdui, and they had to build their own style systems. what i didn't see was anything about animaton / state transition requirements and what isn't in scope (e.g. feed starving children, improve Qt's model/view painting with delegates). Regarding animation/states: it seems like it's something to be implemented by specific styles and/or widgets. The idea here is to provide a Styling mechanism that is flexible enough to support whatever look and feel designers want. That includes animations, but no dedicated infrastructure was thought for that. Cheers, Artur, Caio and Eduardo -- Caio Marcelo de Oliveira Filho OpenBossa - INdT ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.5 - Activities
On March 31, 2010 11:37:51 Aaron J. Seigo wrote: On March 31, 2010, Ivan Čukić wrote: can we get together on irc soon and do a once-over of this and then get it moved into kdereview? Ok, I'll try to be online tomorrow. If not, then the weekend? sounds great; i'll be around :) hey guys, did this happen? is it in review yet? huh? huh? *bounces* I wanna play with it *now*! ;) looking at the API I think I might want a convenience function or two later... but those can always be added on once they're actually needed. let's keep it minimal right now :) -- 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: 4.5 - Activities
btw, at this moment I am editing Plasma::Context to return some made-up activities for testing. I have a midterm tomorrow, but chances are by friday or saturday I'll be itching to put some *real* data in there... :) -- 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: global menu bar for gsoc
On April 6, 2010, Michael Zanetti wrote: On Sunday 04 April 2010 22:17:23 Aaron J. Seigo wrote: On April 4, 2010, Ivan Ruchkin wrote: Why can't we just take the dbus client-server mechanism from Bespin and XBar? Menubar containment will serve as server and every application as a client. that's certainly a possibility. always nice to avoid reinventing the wheel. i haven't looked at how Bespin does it exactly, yet, so have to reserve some judgement. Since this topic is currently discussed I think it makes sense to share a patch that extracts the client side of bespin and applies to the oxygen kstyle interesting; i wonder if this could be put into KStyle itself. -- 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
Re: 4.5 - Activities
On Wednesday 07 April 2010 Chani wrote: On March 31, 2010 11:37:51 Aaron J. Seigo wrote: On March 31, 2010, Ivan Čukić wrote: can we get together on irc soon and do a once-over of this and then get it moved into kdereview? Ok, I'll try to be online tomorrow. If not, then the weekend? sounds great; i'll be around :) hey guys, did this happen? No, both Aaron and myself were a bit offline during the festivities. And I was in a rush these few days since. I'll try to find him today. is it in review yet? huh? huh? *bounces* I wanna play with it *now*! ;) looking at the API I think I might want a convenience function or two later... but those can always be added on once they're actually needed. let's keep it minimal right now :) Cheerio, Ivan -- I am a spokesman for a better way of living Love is the word and it can be heard If you are young the message can be sung -- Deep Purple ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
