Re: Review request: New share dataengine for plasma
On Sunday 01 August 2010 23:16:27 Aaron J. Seigo wrote: supports different mimetypes and because of that more plasmoids and applications will make use of that from my point of view. does this mean we should be thinking about a move to kdebase with the other general interest dataengines? I think yes. While this engine has come out of the pastebin Plasmoid, I can imagine it being used in other places as well, basically as a share button for different media, making it easy to upload the file somewhere and place a link. (Makes sense for Microblog clients as twitpic function, but also for ksnapshot, in email clients, etc.. I think this is where this functionality should ultimately lead to. Am I right, Artur? :) Cheers, -- 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: Review request: New share dataengine for plasma
On Tue, Aug 3, 2010 at 9:03 AM, Sebastian Kügler se...@kde.org wrote: I think yes. While this engine has come out of the pastebin Plasmoid, I can imagine it being used in other places as well, basically as a share button for different media, making it easy to upload the file somewhere and place a link. (Makes sense for Microblog clients as twitpic function, but also for ksnapshot, in email clients, etc.. I think this is where this functionality should ultimately lead to. Am I right, Artur? :) You are right Sebastian, that's the goal. As this is the goal I'm really worried if the code that I did is good enough to support all these use cases and that's where I need the help of you guys to help me sort out any blockers on the current architecture :) Cheers! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: New share dataengine for plasma
On Tuesday 03 August 2010 15:12:18 Artur Souza (MoRpHeUz) wrote: On Tue, Aug 3, 2010 at 9:03 AM, Sebastian Kügler se...@kde.org wrote: I think yes. While this engine has come out of the pastebin Plasmoid, I can imagine it being used in other places as well, basically as a share button for different media, making it easy to upload the file somewhere and place a link. (Makes sense for Microblog clients as twitpic function, but also for ksnapshot, in email clients, etc.. I think this is where this functionality should ultimately lead to. Am I right, Artur? :) You are right Sebastian, that's the goal. As this is the goal I'm really worried if the code that I did is good enough to support all these use cases and that's where I need the help of you guys to help me sort out any blockers on the current architecture :) Sure thing. I'll have a look once we got 4.5.0 out. :) -- 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
Review Request: Fixing positions on the fifteenPuzzle to make it solvable
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4867/ --- Review request for Plasma and Aaron Seigo. Summary --- Previously, the initial piece arrangement for the fifteenPuzzle was: - 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 This arrangement makes the puzzle unsolvable. So the correct initial position must be with the empty space on the last tile, instead of the first. Diffs - /trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp 1158347 /trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp 1158347 Diff: http://reviewboard.kde.org/r/4867/diff Testing --- Thanks, Alex ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Increased steps for randomizing on the fifteenPuzzle plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4868/ --- Review request for Plasma and Aaron Seigo. Summary --- Size^2 steps for randomizing are not enough. 4x4 puzzles could be solved in less than 5 seconds. The number of steps is increased to size^3, which manages to effectively scramble the board. Diffs - /trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp 1158351 Diff: http://reviewboard.kde.org/r/4868/diff Testing --- Thanks, Alex ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Enable the boundingRect to grow along with the board on the fifteenPuzzle plasmoid.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4869/ --- Review request for Plasma and Aaron Seigo. Summary --- When the plasmoid was resized (enlarged), the boundingRect for the pieces remained at the same size, which made the pieces clickable only at the top-left corner (within the size of the original piece). This patch corrects it. Diffs - /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp 1158348 /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/piece.h 1158348 /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp 1158348 Diff: http://reviewboard.kde.org/r/4869/diff Testing --- Thanks, Alex ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 07/23/2010 10:38 AM, Ivan Čukić wrote:
by this score and combine that with the restrictions you list which can
all be expressed using a single Term.
Ok
kstandardactions) and add the method and the enum to the
Nepomuk::Query::StandardQueries namespace.
Yet another Ok :)
please check the attached header and tell me if the API is acceptable. I
did not define special standard queries for fav res of type X since
that ca easily be done via:
Query q = standardQuery(MostImportantResourcesQuery);
q.setTerm( ResourceTypeTerm(type) q.term() );
Also I am not quite sure what for an application would mean in a query...
- only resources that have an event related to the app
- only resources of supported mimetype or resource type
both do not really seem useful though as IMHO there would be too many
false-negatives.
Cheers,
Sebastian
/*
This file is part of the Nepomuk KDE project.
Copyright (C) 2010 Sebastian Trueg tr...@kde.org
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) version 3, or any
later version accepted by the membership of KDE e.V. (or its
successor approved by the membership of KDE e.V.), which shall
act as a proxy defined in Section 6 of version 3 of the license.
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
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library. If not, see http://www.gnu.org/licenses/.
*/
#ifndef _NEPOMUK_STANDARD_QUERIES_H_
#define _NEPOMUK_STANDARD_QUERIES_H_
#include nepomukquery_export.h
#include QtCore/QDate
namespace Nepomuk {
namespace Query {
class Query;
/**
* A set of predefined queries that can be created vis standardQuery().
*
* \since 4.6
*/
enum StandardQuery {
/**
* Creates a query that returns all files sorted by descending modification date.
*/
LastModifiedFilesQuery,
/**
* Creates a query that returns all resources sorted by descending score (as calculated
* by the DataMaintenanceService)
*/
MostImportantResourcesQuery,
/**
* Creates a query that returns all files with a usage count of 0
* sorted by descending modification date.
*/
NeverOpenedFilesQuery
};
/**
* Modificators to influence the behaviour of dateRangeQuery().
*
* \since 4.6
*/
enum DateRangeFlag {
/**
* Query for the modification date (nie:lastModified)
*/
ModificationDate = 0x1,
/**
* Query for the content creation date (nie:contentCreated)
*/
ContentDate = 0x2,
/**
* Query for usage events referring to the resource.
*/
UsageDate = 0x4,
/**
* Query for all possible dates.
*/
AllDates = ModificationDate|ContentDate|UsageDate
};
Q_DECLARE_FLAGS( DateRangeFlags, DateRangeFlag )
/**
* Create a standard query as defined by \p query.
* To get a query that only returns files (this is already true for some of the predefined queries)
* use something like the following:
*
* \code
* Query::FileQuery query = Query::standardQuery( Query::LastModifiedFilesQuery );
* \endcode
*
* \since 4.6
*/
NEPOMUK_QUERY_EXPORT Query standardQuery( StandardQuery query );
/**
* Create a query that returns resources/files that have been modified/accessed in the range
* from \p start to \p end. The flags specified in \p dateFlags can be used to influence the
* type of dates that are queried.
*
* \since 4.6
*/
NEPOMUK_QUERY_EXPORT Query dateRangeQuery( const QDate start, const QDate end, DateRangeFlags dateFlags = AllDates );
}
}
Q_DECLARE_OPERATOR_FOR_FLAGS( Nepomuk::Query::DateRangeFlags )
#endif
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Adding a chronometer to the fifteenPuzzle plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4870/ --- Review request for Plasma and Aaron Seigo. Summary --- This patch implements a chronometer for solving the puzzle. It starts as soon as it is shuffled, and automatically ends when the puzzle is sorted. A Plasma::Dialog is shown with the time elapsed after sorting out. Diffs - /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.h 1158685 /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp 1158685 /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzle.h 1158685 /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzle.cpp 1158685 Diff: http://reviewboard.kde.org/r/4870/diff Testing --- Probably it would only be testable if the position patch is applied, since the initial positions on the current revision create an unsolvable puzzle. Thanks, Alex ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Enable the boundingRect to grow along with the board on the fifteenPuzzle plasmoid.
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4869/#review6770 --- Ship it! there's one small improvement to be made (see comment below), and this can go in as the fix is correct. (do you have an svn account?) /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp http://reviewboard.kde.org/r/4869/#comment6581 this is, in fact, what the default implementation of QGraphicsItem::boundingRect() does. so this method can be completely removed. - Aaron On 2010-08-03 15:48:24, Alex Raymond wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4869/ --- (Updated 2010-08-03 15:48:24) Review request for Plasma and Aaron Seigo. Summary --- When the plasmoid was resized (enlarged), the boundingRect for the pieces remained at the same size, which made the pieces clickable only at the top-left corner (within the size of the original piece). This patch corrects it. Diffs - /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp 1158348 /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/piece.h 1158348 /trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp 1158348 Diff: http://reviewboard.kde.org/r/4869/diff Testing --- Thanks, Alex ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fixing positions on the fifteenPuzzle to make it solvable
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4867/#review6772 --- /trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp http://reviewboard.kde.org/r/4867/#comment6586 would it make more sense to just pass in a larger id number when Pieces are created instead of adding one to the id here? that way the id passed to Piece are the id's they'll actually have. i find such consistency makes code easier to maintain over time. :) /trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp http://reviewboard.kde.org/r/4867/#comment6583 here's another m_id == 0 that has been missed. perhaps instead of comparing against a magic id number, there should be a boolean member in Piece that holds whether or not it is a blank piece and then that can be calculated exactly once in the constructor. - Aaron On 2010-08-03 15:34:07, Alex Raymond wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4867/ --- (Updated 2010-08-03 15:34:07) Review request for Plasma and Aaron Seigo. Summary --- Previously, the initial piece arrangement for the fifteenPuzzle was: - 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 This arrangement makes the puzzle unsolvable. So the correct initial position must be with the empty space on the last tile, instead of the first. Diffs - /trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp 1158347 /trunk/KDE/kdeplasma-addons/applets/fifteenPuzzle/src/piece.cpp 1158347 Diff: http://reviewboard.kde.org/r/4867/diff Testing --- Thanks, Alex ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Adding a chronometer to the fifteenPuzzle plasmoid
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4870/#review6771
---
Ship it!
looks good, apart some tiny issues of coding convention and a comment of the
label creation.
other than that it can go in
/trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.h
http://reviewboard.kde.org/r/4870/#comment6582
whitespace :)
/trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp
http://reviewboard.kde.org/r/4870/#comment6584
if (sorted wasShuffled) {
i know the rest doesn't really follow the conventions but would be good to
slowly start to convert it
/trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzle.h
http://reviewboard.kde.org/r/4870/#comment6585
whitespace
/trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzle.cpp
http://reviewboard.kde.org/r/4870/#comment6588
maybe the label could be created on demand, to make it lighter
- Marco
On 2010-08-03 15:56:36, Alex Raymond wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4870/
---
(Updated 2010-08-03 15:56:36)
Review request for Plasma and Aaron Seigo.
Summary
---
This patch implements a chronometer for solving the puzzle. It starts as soon
as it is shuffled, and automatically ends when the puzzle is sorted. A
Plasma::Dialog is shown with the time elapsed after sorting out.
Diffs
-
/trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.h 1158685
/trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteen.cpp 1158685
/trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzle.h
1158685
/trunk/KDE//kdeplasma-addons/applets/fifteenPuzzle/src/fifteenPuzzle.cpp
1158685
Diff: http://reviewboard.kde.org/r/4870/diff
Testing
---
Probably it would only be testable if the position patch is applied, since
the initial positions on the current revision create an unsolvable puzzle.
Thanks,
Alex
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
- only resources that have an event related to the app ^^ to be used instead of the 'recently opened documents' both do not really seem useful though as IMHO there would be too many false-negatives. If the app uses this system to notify us of open/modify/close events, there wouldn't be any false-negatives. If not, then it can't really expect the above to work. please check the attached header and tell me if the API is acceptable. I did not define special standard queries for fav res of type X since that ca easily be done via: How do we get MostImportantResources for a specific activity? Intersecting the results of MIR and resources-related-to-DE-related-to-activity? Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Maximum height of a TreeView within a TabBar
On Tuesday 03 August 2010, Glenn Wurster wrote: Greetings, I've been attempting to develop a Plasma applet using Python. I'm having an issue, however, with the height of the Plasma::TreeView being artificially constrained if I embed it in a Plasma::TabBar. If I put the TreeView directly onto the plasma applet without the TabBar, the height of the TreeView expands to take up all available space in the window. If, instead, I place the TreeView in a TabBar, the height of the TreeView will not expand past a certain point (the width does not seem similarly constrained). I've tried setting the maximum height on both TabBar and the inner TreeView element (using setMaximumHeight) to no avail. you can try to set the vertical size policy of the treeview to Expanding Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 08/03/2010 08:41 PM, Ivan Čukić wrote:
I know you're going to hate me, but I have to - recent documents in
the app should be restricted to the activity as well.
Would it work if the term provided would be ResTerm('activity')
ResTerm('application')
Currently this
Comparison( xxx, ResTerm(a) ResTerm(b) )
would result in a broken query.
I could add support for that in the standardQuery call though. But then
again what did we decide? Will the activity be linked to the graph or
the event? I think it was the former in which case we need two different
terms anyway which means we could use the approach of combining standard
queries like so:
standardQuery( ResourcesForActivityQuery, ResourceTerm(activity) )
standardQuery( ResourcesForApplicationQuery, ResourceTerm(app) )
standardQuery( MostImportantResourcesQuery )
IMO, the enum approach provides versatility on one level, but can be
rather restricting if we don't cover most of the use-cases at the
beginning.
how so? and which approach is better? Adding dedicated methods for all
cases has no advantage since that can be done at any point in time once
we reach the boundaries of the enum approach.
But if you don't like the enum - we can also use dedicated methods. I
just think a combination to keep the number of methods small makes sense.
And I also added a hint as to how standard queries can be combined to
I didn't see the hint here
it is in the docs for standardQuery.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
