Re: qml systemtray: small refactorings
On Friday, October 26, 2012 10:53:03 Luca Beltrame wrote: > In data venerdì 26 ottobre 2012 12:46:59, Dmitry Ashkadov ha scritto: > > (plasma/dmitrya/systemtray-qml), but I can't delete old branch (: Remote > > git server refuses my attempts > > Only repo admins can delete branches. ... which i have just done :) -- Aaron J. Seigo 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: qml systemtray: small refactorings
In data venerdì 26 ottobre 2012 12:46:59, Dmitry Ashkadov ha scritto: > (plasma/dmitrya/systemtray-qml), but I can't delete old branch (: Remote > git server refuses my attempts Only repo admins can delete branches. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 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: qml systemtray: small refactorings
26.10.2012 12:38, Aaron J. Seigo пишет: On Friday, October 26, 2012 11:35:57 Dmitry Ashkadov wrote: Thank you! Is somebody who periodically merges KDE 4.X to master or it must be made by who fixes bug? the bug fixer; kdelibs is different -> it is merged periodically by someone (usually dfaure). hopefully in future all our core modules will be like this. but we're missing integration maintainers right now. i'm going to be dong this for plasma-mobile, btw, and when kde-workspace moves eventually to the future Frameworks 5 libraries i'd like at that point to also move kde-workspace to an "integration maintainer" style. but for now .. yes, it's up to each bug fixer (meh! :) If I do some refactoring what branch should I use? As I understand I should use master and my changes will be brought to next KDE release (4.11) only? master is still 4.10 .. 4.10 has not yet been branched and won't be until sometime around the Release Candidates in a couple months time. so just go to work in master; or better -> work in a local branch and when it's in good shape then merge your local branch into master and push to origin/master. i suggest this because it lets you quickly switch back to master without losing work and if your refactoring goes badly then you can just start again very easily :) this tends to be what i do in such situations and it has saved me lots of effort more than once! I thought that soft freeze ends with creating KDE4.10 branch... I'd like create new branch from master and delete old branch (plasma/dmitrya/systemtray-qml), but I can't delete old branch (: Remote git server refuses my attempts ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml systemtray: small refactorings
On Friday, October 26, 2012 11:35:57 Dmitry Ashkadov wrote: > Thank you! Is somebody who periodically merges KDE 4.X to master or it > must be made by who fixes bug? the bug fixer; kdelibs is different -> it is merged periodically by someone (usually dfaure). hopefully in future all our core modules will be like this. but we're missing integration maintainers right now. i'm going to be dong this for plasma-mobile, btw, and when kde-workspace moves eventually to the future Frameworks 5 libraries i'd like at that point to also move kde-workspace to an "integration maintainer" style. but for now .. yes, it's up to each bug fixer (meh! :) > If I do some refactoring what branch should I use? As I understand I > should use master and my changes will be brought to next KDE release > (4.11) only? master is still 4.10 .. 4.10 has not yet been branched and won't be until sometime around the Release Candidates in a couple months time. so just go to work in master; or better -> work in a local branch and when it's in good shape then merge your local branch into master and push to origin/master. i suggest this because it lets you quickly switch back to master without losing work and if your refactoring goes badly then you can just start again very easily :) this tends to be what i do in such situations and it has saved me lots of effort more than once! -- Aaron J. Seigo 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: qml systemtray: small refactorings
26.10.2012 10:50, Aaron J. Seigo пишет: On Friday, October 26, 2012 10:04:24 Dmitry Ashkadov wrote: Thank you for your answer. What workflow does KDE team use to bring changes from master branch to KDE4.X branch? For example, some fixes should be applied to master and KDE4.X branches at the same time. if they are bug fixes, then the preferred means is to do them in the latest stable branch (e.g. 4.10 or whatever) and then merge that into master; if merge fails due to conflicts (which often happens eventually over the course of a devel cycle) then we restor to cherry-picks from branch into master. Thank you! Is somebody who periodically merges KDE 4.X to master or it must be made by who fixes bug? If I do some refactoring what branch should I use? As I understand I should use master and my changes will be brought to next KDE release (4.11) only? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml systemtray: small refactorings
On Friday, October 26, 2012 10:04:24 Dmitry Ashkadov wrote: > Thank you for your answer. What workflow does KDE team use to bring > changes from master branch to KDE4.X branch? For example, some fixes > should be applied to master and KDE4.X branches at the same time. if they are bug fixes, then the preferred means is to do them in the latest stable branch (e.g. 4.10 or whatever) and then merge that into master; if merge fails due to conflicts (which often happens eventually over the course of a devel cycle) then we restor to cherry-picks from branch into master. -- Aaron J. Seigo 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: qml systemtray: small refactorings
26.10.2012 09:51, Luca Beltrame пишет: In data venerdì 26 ottobre 2012 09:40:25, Dmitry Ashkadov ha scritto: branch should I use to make some refactoring/changes? As I know today 4.10 branch must be created. Today marks the *soft* feature freeze: in other words, not yet frozen for new features, there's just a limit to new features being introduced (but these adjustments don't qualify IMO as completely new features). Hard feature freeze (a proper freeze, in that case) is later on. So for now I think you can work directly in master. Thank you for your answer. What workflow does KDE team use to bring changes from master branch to KDE4.X branch? For example, some fixes should be applied to master and KDE4.X branches at the same time. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml systemtray: small refactorings
In data venerdì 26 ottobre 2012 09:40:25, Dmitry Ashkadov ha scritto: > branch should I use to make some refactoring/changes? As I know today > 4.10 branch must be created. Today marks the *soft* feature freeze: in other words, not yet frozen for new features, there's just a limit to new features being introduced (but these adjustments don't qualify IMO as completely new features). Hard feature freeze (a proper freeze, in that case) is later on. So for now I think you can work directly in master. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 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: qml systemtray: small refactorings
26.10.2012 00:43, Aaron J. Seigo пишет: hi... i suppose this is mostly for Dmitry, but its nice to have these discussions here :) so .. system tray plasmoid. works pretty well it seems. :) Hello! Thank you for your questions! But first of all, I'd like to know what branch should I use to make some refactoring/changes? As I know today 4.10 branch must be created. I don't understand why every task can have different widgets for different hosts (applets): QHash widgetsByHost() const; Is it really possible to have few applets in one applet? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
qml systemtray: small refactorings
hi...
i suppose this is mostly for Dmitry, but its nice to have these discussions
here :)
so .. system tray plasmoid. works pretty well it seems. :)
started looking through the code a bit more deeply and i think we can start to
tighten it up a bit.
for example, it seems that TasksPool duplicates Manager. the only thing
TasksPool really adds is a QVariantHash and access to the host applet. this
probably could just be a QHash though (skipping all the
QVariant overhead) and added to Manager.
to have this hash work in the QML, it is probably necessary to do sth like:
namespace SystemTray {
typedef QHash ObjectHash;
}
Q_DECLARE_METATYPE(SystemTray::ObjectHash)
qRegisterMetaType("ObjectHash")
that should hopefully let it work via QVariant properly. (the first 3 lines go
into headers, the 3 line into C++ somewhere)
UiTask is also ripe for some refactoring, as it's really just a proxy for
Task. the TaskType enum should go into Task itself, and a QString id() const
method should be added to Task as well. that really just leaves how to get at
the host applet pointer so that the widget can be retrieved.
the applet pointer could be made available to the QML and then WidgetItem
could have an applet (or host?) property which it would use to derive its
widget().
then TasksPool is not needed for the host applet pointer. UiTask becomes just
Task, and Manager can be used directly instead of TasksPool in the QML.
something else I don't quite understand from the code is why QObjects, which
import into QML just fine, are turned in QVariants everywhere before being sent
into the QML?
and example is in WidgetItem:
Q_PROPERTY(QVariant widget READ widget WRITE setWidget NOTIFY
changedWidget) ///< widget to embed
all it does is return a QObject pointer.. QML *should* handle that just fine,
and when i changed it to be just a QObject, it indeed continued to work as
expected. (i've even pushed that change)
.. there's probably more, but this is probably a good start. what's there now
is functional and definitely decent code to be certain; it's just nice to make
it as smooth as possible so maintenance later is easier :)
p.s. i'd also like to get rid of all the private pimpl classes; this is not a
library after all :)
--
Aaron J. Seigo
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
