Re: Review Request: Frame applet should give valid message when dropped folder doesn't have any images
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5362/#review7637 --- Ship it! One small issue with i18n context left, otherwise it's good to go in (from my point of view, better wait for annma to mark it as ship it as well). trunk/KDE/kdeplasma-addons/applets/frame/picture.cpp http://svn.reviewboard.kde.org/r/5362/#comment7791 i18n context should be more useful. - Sebastian On 2010-09-16 03:54:44, Sujith H wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5362/ --- (Updated 2010-09-16 03:54:44) Review request for Plasma. Summary --- This diff will give the user meaningful message when a folder is dropped to the frame applet and if it doesn't contain image(s). Diffs - trunk/KDE/kdeplasma-addons/applets/frame/picture.h 1174498 trunk/KDE/kdeplasma-addons/applets/frame/picture.cpp 1174498 trunk/KDE/kdeplasma-addons/applets/frame/slideshow.h 1174498 trunk/KDE/kdeplasma-addons/applets/frame/slideshow.cpp 1174498 Diff: http://svn.reviewboard.kde.org/r/5362/diff Testing --- This has been tested. Thanks, Sujith ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Frame applet should give valid message when dropped folder doesn't have any images
On 2010-09-16 11:20:34, Sebastian Kügler wrote: trunk/KDE/kdeplasma-addons/applets/frame/picture.cpp, line 88 http://svn.reviewboard.kde.org/r/5362/diff/4/?file=36015#file36015line88 i18n context should be more useful. I agree with Sebas, ship it and thanks for looking in this issue! As for the context help for translators, maybe we can put i18nc(Text written on default picture, Dropped folder is empty. Please drop a folder with image(s)); - Anne-Marie --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5362/#review7637 --- On 2010-09-16 03:54:44, Sujith H wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5362/ --- (Updated 2010-09-16 03:54:44) Review request for Plasma. Summary --- This diff will give the user meaningful message when a folder is dropped to the frame applet and if it doesn't contain image(s). Diffs - trunk/KDE/kdeplasma-addons/applets/frame/picture.h 1174498 trunk/KDE/kdeplasma-addons/applets/frame/picture.cpp 1174498 trunk/KDE/kdeplasma-addons/applets/frame/slideshow.h 1174498 trunk/KDE/kdeplasma-addons/applets/frame/slideshow.cpp 1174498 Diff: http://svn.reviewboard.kde.org/r/5362/diff Testing --- This has been tested. Thanks, Sujith ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: new kwin effect: roundedcorners - make corners of the desktop rounded
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5225/ --- (Updated 2010-09-16 12:35:26.606956) Review request for kwin, Plasma and Martin Gräßlin. Changes --- Thanks a lot for reviews and comments. This is a new round to meet annotations by Martin Gräßlin. Summary --- Inspired by roundedge http://www.nongnu.org/roundedge/ this kwin effect makes corners of the desktop rounded. Older Macs and Monitors had this feature too. Diffs (updated) - tags/KDE/4.5.1/kdebase/workspace/kwin/effects/CMakeLists.txt 1170001 tags/KDE/4.5.1/kdebase/workspace/kwin/effects/configs_builtins.cpp 1170001 tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/CMakeLists.txt PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/roundedcorners.desktop PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/roundedcorners.h PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/roundedcorners.cpp PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/roundedcorners_config.h PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/roundedcorners_config.cpp PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/roundedcorners_config.desktop PRE-CREATION tags/KDE/4.5.1/kdebase/workspace/kwin/effects/roundedcorners/roundedcorners_config.ui PRE-CREATION Diff: http://svn.reviewboard.kde.org/r/5225/diff Testing --- Screenshots --- roundedcorners_without_frame http://svn.reviewboard.kde.org/r/5225/s/498/ with_simulated_border http://svn.reviewboard.kde.org/r/5225/s/499/ Thanks, Christoph ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
QML and Plasma - progress()
Hi all,
the status of an AppletScript for writing plasmoids in pure QML is progressing
rather well, i thought to write a detailed status report/documentation before
significative design problems go too far in the implementation, be patient, is
really long, but it can be used as a basis for a future documentation.
* It is now possible to have packages that specify a main qml file, just like
js plasmoids.
* Plasma widgets are binded in the QML language, with the Plasma.* prefix
* QGraphicsLayouts are binded in plasma bindings themselves, it is not going
to be in Qt sadly (but QGraphicsWidget subclasses are starting to work pretty
well with anchors/positioners as well)
* Plasma::Svg and FrameSvg are implemented as QDeclarativeItem subclasses
binded as Svg and FrameSvg. in the future plasma widgets are going to be
reimplemented in QML probably, those will be the classes for theming
To use QML in Plasma there are 2 ways:
* Plasma::QMLWidget - i a qgraphicswidget that loads a qml file in it, and
keeps the context/engine/etc, it shortens an otherwise long and repetitive
task of loding qml files with eventiual parse error management, to be used in
c++ plasmoids, where complex logic is needed.
* QML AppletScript: to write applets completely in QML, (uses a QMLWidget
internally)
* only pure qml applets will have access to the plasmoid object? (or, the
plasmoid object could be registered from QMLWidget, only when it is actually
descendent of an Applet, but it would have to be in libplasma, instead of in
workspace/runtime)
* Package: as in js bindings the package name resolution is accessible from
plasmoid.file()
* Theme: defining a Plasma.Theme{} element in qml will obtain an object with
the Plasma colors as properties - should be an object always registered to
the root context instead? maybe by QMLWidget itself so it is always
accessible?
* DataEngine: a Plasma.DataSource{} object can be defined in QML, this
connects to a single dataengine source, das the source, dataengine and
interval properties. its Data property is a QDeclarativePropertyMap, that maps
perfectly DataEngine::Data (but is a qobject, so it can notify all properties
that change) to access the time of the tiime dataengine one can do:
dataSource.data.time .
This can be used from both qml plasmoids or outside. I'm not completely
sure it's the right approach, alternatively in the dataUpdated of the
AppletScript QDeclarativePropertyMaps named as something like
dataengine+source could be assigned to the root context, connections would be
done in the oncomplete{} slot of qml items. uhm... in the end i think i'll
leave the DataSource approach.
* Service: still to be defined, if Plasma.DataSource is the right way to go,
it could have a service() method that would essentially call serviceForSource,
then bindings for kconfig would be needed, but this part is still fggy to me.
* Something else forgotten?
Here is the status of the support to Applet properties and methods:
== Methods that the ql applets should be able to reimplement: ==
* paintInterface - no, no access to qpainters here (and was quickly becoming
deprecated anyways)
* constraintsEvent - formfactor, location, immutable and currentActivity
become notifying properties - property binding
* dataUpdated: DataSource qml item: alternative is to set a
QDeclarativePropertyMap on dataupdated - but would be good to use it also in
c++ plasmoids
* configChanged() - qml applet reimplements configChanged() function in root
Item
* popupEvent() - qml applet reimplements popupEvent() function in the root
Item
== Plasmoid functions/properties ==
Unique plasmoid oject registered in the root context
shamelessy copied from the js bindings has the following stuff:
--properties (AppletInterface):
* aspectRatioMode
* formFactor NORIFY formFactorChanged()
* location NOTIFY locationChanged()
* currentActivity NOTIFY contextChanged()
* shouldConserveResources
* activeConfig
* busy
* backgroundHints
* immutable NOTIFY immutableChanged()
* userConfiguring
* apiVersion CONSTANT
* rect
* size
--properties (PopupAplletInterface):
* popupIcon - needs QIcon bindings for QML
* passivePopup
* popupWidget - is it useful there?
Should all properties that are not CONSTANT have a NOTIFY signal? that is
needed for qml property binding.
--methods (AppletInterface):
* void setFailedToLaunch(bool failed, const QString reason = QString())
* void setConfigurationRequired(bool needsConfiguring, const QString reason =
QString())
* void setAction(const QString name, const QString text,
const QString icon = QString(), const QString shortcut =
QString());
* void removeAction(const QString name);
* void resize(qreal w, qreal h);
* void setMinimumSize(qreal w, qreal h);
* void setPreferredSize(qreal w, qreal h);
* QVariant readConfig(const QString entry) const;
* void writeConfig(const QString entry, const QVariant value);
* QString file(const QString fileType);
R: QML and Plasma - progress()
Extremely interesting... this will open new possibilities.
Will these functionalities implemented into PlasMate, to
give developers a simple way to write QML plasma widgets?
Luca Tringali
Messaggio originale
Da: notm...@gmail.com
Data: 16/09/2010 15.11
A: Plasmaplasma-devel@kde.org
Ogg: QML and Plasma -gt; progress()
Hi all,
the status of an AppletScript for writing plasmoids in pure QML is
progressing
rather well, i thought to write a detailed status report/documentation
before
significative design problems go too far in the implementation, be patient,
is
really long, but it can be used as a basis for a future documentation.
* It is now possible to have packages that specify a main qml file, just
like
js plasmoids.
* Plasma widgets are binded in the QML language, with the Plasma.* prefix
* QGraphicsLayouts are binded in plasma bindings themselves, it is not going
to be in Qt sadly (but QGraphicsWidget subclasses are starting to work
pretty
well with anchors/positioners as well)
* Plasma::Svg and FrameSvg are implemented as QDeclarativeItem subclasses
binded as Svg and FrameSvg. in the future plasma widgets are going to be
reimplemented in QML probably, those will be the classes for theming
To use QML in Plasma there are 2 ways:
* Plasma::QMLWidget - i a qgraphicswidget that loads a qml file in it, and
keeps the context/engine/etc, it shortens an otherwise long and repetitive
task of loding qml files with eventiual parse error management, to be used
in
c++ plasmoids, where complex logic is needed.
* QML AppletScript: to write applets completely in QML, (uses a QMLWidget
internally)
* only pure qml applets will have access to the plasmoid object? (or, the
plasmoid object could be registered from QMLWidget, only when it is actually
descendent of an Applet, but it would have to be in libplasma, instead of in
workspace/runtime)
* Package: as in js bindings the package name resolution is accessible from
plasmoid.file()
* Theme: defining a Plasma.Theme{} element in qml will obtain an object with
the Plasma colors as properties - should be an object always registered to
the root context instead? maybe by QMLWidget itself so it is always
accessible?
* DataEngine: a Plasma.DataSource{} object can be defined in QML, this
connects to a single dataengine source, das the source, dataengine and
interval properties. its Data property is a QDeclarativePropertyMap, that
maps
perfectly DataEngine::Data (but is a qobject, so it can notify all
properties
that change) to access the time of the tiime dataengine one can do:
dataSource.data.time .
This can be used from both qml plasmoids or outside. I'm not completely
sure it's the right approach, alternatively in the dataUpdated of the
AppletScript QDeclarativePropertyMaps named as something like
dataengine+source could be assigned to the root context, connections would
be
done in the oncomplete{} slot of qml items. uhm... in the end i think i'll
leave the DataSource approach.
* Service: still to be defined, if Plasma.DataSource is the right way to go,
it could have a service() method that would essentially call
serviceForSource,
then bindings for kconfig would be needed, but this part is still fggy to me.
* Something else forgotten?
Here is the status of the support to Applet properties and methods:
== Methods that the ql applets should be able to reimplement: ==
* paintInterface - no, no access to qpainters here (and was quickly
becoming
deprecated anyways)
* constraintsEvent - formfactor, location, immutable and currentActivity
become notifying properties - property binding
* dataUpdated: DataSource qml item: alternative is to set a
QDeclarativePropertyMap on dataupdated - but would be good to use it also
in
c++ plasmoids
* configChanged() - qml applet reimplements configChanged() function in
root
Item
* popupEvent() - qml applet reimplements popupEvent() function in the root
Item
== Plasmoid functions/properties ==
Unique plasmoid oject registered in the root context
shamelessy copied from the js bindings has the following stuff:
--properties (AppletInterface):
* aspectRatioMode
* formFactor NORIFY formFactorChanged()
* location NOTIFY locationChanged()
* currentActivity NOTIFY contextChanged()
* shouldConserveResources
* activeConfig
* busy
* backgroundHints
* immutable NOTIFY immutableChanged()
* userConfiguring
* apiVersion CONSTANT
* rect
* size
--properties (PopupAplletInterface):
* popupIcon - needs QIcon bindings for QML
* passivePopup
* popupWidget - is it useful there?
Should all properties that are not CONSTANT have a NOTIFY signal? that is
needed for qml property binding.
--methods (AppletInterface):
* void setFailedToLaunch(bool failed, const QString reason = QString())
* void setConfigurationRequired(bool needsConfiguring, const QString reason
=
QString())
* void setAction(const QString name, const QString text,
const QString icon = QString(), const
Re: QML and Plasma - progress()
On Thursday 16 September 2010 15:11:42 Marco Martin wrote:
* Plasma widgets are binded in the QML language, with the Plasma.* prefix
* QGraphicsLayouts are binded in plasma bindings themselves, it is not going
to be in Qt sadly (but QGraphicsWidget subclasses are starting to work
pretty well with anchors/positioners as well)
* Plasma::Svg and FrameSvg are implemented as QDeclarativeItem subclasses
binded as Svg and FrameSvg. in the future plasma widgets are going to be
reimplemented in QML probably, those will be the classes for theming
Awesome work Marco! :D
To use QML in Plasma there are 2 ways:
* Plasma::QMLWidget - i a qgraphicswidget that loads a qml file in it, and
keeps the context/engine/etc, it shortens an otherwise long and repetitive
task of loding qml files with eventiual parse error management, to be used
in c++ plasmoids, where complex logic is needed.
Maybe call it Plasma::DeclarativeWidget instead of Plasma::QMLWidget? Not sure
about this though, just something that crossed my mind (as the Qt item is
QDeclarativeItem).
* Theme: defining a Plasma.Theme{} element in qml will obtain an object with
the Plasma colors as properties - should be an object always registered
to the root context instead? maybe by QMLWidget itself so it is always
accessible?
Good question. At first I thought about sure, let's put it directly on the
root context. Now I'm not so sure again :P But I would say that yes, it may
be a good idea to already put in the root context :)
* DataEngine: a Plasma.DataSource{} object can be defined in QML, this
connects to a single dataengine source, das the source, dataengine and
interval properties. its Data property is a QDeclarativePropertyMap, that
maps perfectly DataEngine::Data (but is a qobject, so it can notify all
properties that change) to access the time of the tiime dataengine one can
do: dataSource.data.time .
\o/
This can be used from both qml plasmoids or outside. I'm not completely
sure it's the right approach, alternatively in the dataUpdated of the
AppletScript QDeclarativePropertyMaps named as something like
dataengine+source could be assigned to the root context, connections would
be done in the oncomplete{} slot of qml items. uhm... in the end i think
i'll leave the DataSource approach.
It seems more declarative using the DataSource approachthe other being
too magical. I don't think it's bad, but the DataSource approach seems just
more declarative and then I would stick with that...
* Service: still to be defined, if Plasma.DataSource is the right way to go,
it could have a service() method that would essentially call
serviceForSource, then bindings for kconfig would be needed, but this part
is still fggy to me.
Aaron did something regarding services for the JS bindings. Or at least he had
a very good idea for it AFAIR.
* paintInterface - no, no access to qpainters here (and was quickly
becoming deprecated anyways)
Another great shoot! +1 for you :D
* constraintsEvent - formfactor, location, immutable and currentActivity
become notifying properties - property binding
Nice..
Unique plasmoid oject registered in the root context
shamelessy copied from the js bindings has the following stuff:
This is something that we need to work out: kde-pim also copies some stuff
from the js binding. If we could share all this stuff it would be great
(instead of duplicating code). But we need to figure out a way of doing this
without having proper access to QML's script engine.
* popupIcon - needs QIcon bindings for QML
The binding could just return directly the pixmap maybe?
Should all properties that are not CONSTANT have a NOTIFY signal? that is
needed for qml property binding.
I think so
===
Great job Marco, and awesome mail :) Thanks for the follow up!
Cheers,
--
---
Artur Duque de Souza - MoRpHeUz
---
http://claimid.com/morpheuz
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
---
signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML and Plasma - progress()
On Thursday 16 September 2010, Aaron J. Seigo wrote: On Thursday, September 16, 2010, Marco Martin wrote: * Plasma::QMLWidget - i a qgraphicswidget that loads a qml file in it, and keeps the context/engine/etc, it shortens an otherwise long and repetitive task of loding qml files with eventiual parse error management, to be used in c++ plasmoids, where complex logic is needed. * QML AppletScript: to write applets completely in QML, (uses a QMLWidget internally) what's the possibility of using QML from a Javascript plasmoid? it is possible, it could get a bit confusing tough. right now it's possible to create from the js plasmoid a qmlwidget and load a qml file from there. the thing that i find a bit weird is the following: it would be possible to have widgets and manage dataengines from the outside javascript and from the qml/javascript that lives inside the widget. the two things would live in two separate worlds, almost incomunicable (thre could be some bindings to getting/setting properties from the objects in the qml context from javascript) there would be two engines, because we again have the problem that the internal script engine of qml is not accessible, that means also if we want to access a plasmoid object from qml or the javascript inside qml we have to use another appletinterface instance (tough registring the same instance in both engines could work withut exploding, it has to be tried) tbh, i'm less interestied in a QMLAppletScript as i am in being able to use QML from inside a Javascript, for a number of reasons including clarity of documentaiton and simplifying the learning curves (one solution rather than multiple ones that you have to decide which is least-worse for your goals) as i said, i don't think would really simplify the learning curve, because one would have to manage two types of javascript, with a difference between them that is quite an implementation detail (being on two engines) now, i'm in favour of trying to do the two things in the same place to share the code of appletinterface, even tough i had to do some modifications to make it work, but i think they managed to make it so alien from a normal QtScript that the two things are not really conciliable anymore, it sucks and i would like to see solutions for it, but i don't think it's feasible Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML and Plasma - progress()
On Thursday, September 16, 2010, Marco Martin wrote: as i said, i don't think would really simplify the learning curve, because one would have to manage two types of javascript, with a difference between them that is quite an implementation detail (being on two engines) is it possible to include() other JS scripts from a QML Plasmoid package? because that's really what i'm most concerned about - being able to use the JS API we have now to drive the QML. as for the engine not beign exposed, well .. i'm not surprised. i have lost faith in the idea that QML development is in the hands of people who are competent enough with design for it to ever be an unqualified success. it will likely remain a land of promises half achieved and possibilities only half realized. i expect it to be forked / re-written (using the same language) at some point in the future with a reasonable API for developers using it. it's QtMultimedia all over again: the same unwaranted bravado, the same potential in the design ideas if not the implementation, the same evident flaws that the developers are closing their ears to and therefore almost certain to have the same kind of result due to that. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML and Plasma - progress()
On Thursday 16 September 2010, Aaron J. Seigo wrote: On Thursday, September 16, 2010, Marco Martin wrote: as i said, i don't think would really simplify the learning curve, because one would have to manage two types of javascript, with a difference between them that is quite an implementation detail (being on two engines) is it possible to include() other JS scripts from a QML Plasmoid package? because that's really what i'm most concerned about - being able to use the JS API we have now to drive the QML. it is possible to include separate js files, yes and as far i know, all we can do to reuse our api is to register qobjects with our api with properties/signals/invokables. AppletInterface works pretty well there, one can just register it t the root context as plasmoid and everything (almost) just works. it is not possible to override plasmoid functions in javascript with things like plasmoid.dataUpdated = function() as far i know, but i could be wrong, i don't thik we really need this tough. i -think- most of our bindings in javascript/simplebindings/ aren't of much use, since they use qscriptvalues, that is another thing that if it's used is buried pretty deep, all you pass around seems to be a simple qvariant, so simple thngs like colors,rects,sizes seems to just work. as for the engine not beign exposed, well .. i'm not surprised. i have lost faith in the idea that QML development is in the hands of people who are competent enough with design for it to ever be an unqualified success. it will likely remain a land of promises half achieved and possibilities only half realized. i expect it to be forked / re-written (using the same language) at some point in the future with a reasonable API for developers using it. it's QtMultimedia all over again: that's what i'm already hearing from several sources, basically wih the language everybody is almost happy, the implementation itself is unlikely to stay for long the same unwaranted bravado, the same potential in the design ideas if not the implementation, the same evident flaws that the developers are closing their ears to and therefore almost certain to have the same kind of result due to that. yeah, what i'm concerned now is us using it in a way that will be as easy as possible to adapt. it's a think that right now works almost well, even with those huge problems, so i think the benefit to use it now is relevant enough, especially if this could become the only thing usable in some qgraphicsview replacement in the future. but plans are so unclear and will change so many thimes still that meh... :/ Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML and Plasma - progress()
On Thursday, September 16, 2010, Marco Martin wrote: On Thursday 16 September 2010, Aaron J. Seigo wrote: On Thursday, September 16, 2010, Marco Martin wrote: as i said, i don't think would really simplify the learning curve, because one would have to manage two types of javascript, with a difference between them that is quite an implementation detail (being on two engines) is it possible to include() other JS scripts from a QML Plasmoid package? because that's really what i'm most concerned about - being able to use the JS API we have now to drive the QML. it is possible to include separate js files, yes and as far i know, all we can do to reuse our api is to register qobjects with our api with properties/signals/invokables. hm.. hopefully that's not too limiting for us. AppletInterface works pretty well there, one can just register it t the root context as plasmoid and everything (almost) just works. great... it is not possible to override plasmoid functions in javascript with things like plasmoid.dataUpdated = function() as far i know, but i could be wrong, i don't thik we really need this tough. it's probably avoidable now that we have event listeners and the ability to connect random functions and objects to signals and what not. overriding functions in plasmoid is indeed probably avoidable now, but it will be desirable with other objects. i -think- most of our bindings in javascript/simplebindings/ aren't of much use, since they use qscriptvalues, that is another thing that if it's used is buried pretty deep, all you pass around seems to be a simple qvariant, so simple thngs like colors,rects,sizes seems to just work. yes, i'm not so concerned about simpmle things like colors, etc. but consistency with things like DataEngines, Services, AddOns, Extensions, etc. it would be great to avoid having two different ways to, for example, respond to events such as addonCreated. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML and Plasma - progress()
On Thursday 16 September 2010, Aaron J. Seigo wrote:
it is not possible to override plasmoid functions in javascript with
things like plasmoid.dataUpdated = function() as far i know, but i could
be wrong, i don't thik we really need this tough.
it's probably avoidable now that we have event listeners and the ability to
connect random functions and objects to signals and what not. overriding
functions in plasmoid is indeed probably avoidable now, but it will be
desirable with other objects.
i found that the following structure looks nice:
in the root element implement a javascript function with the proper name, like
Item {
function configChangd()
{
do stuff
}
}
and then call it from the appletscript c++ when it's necessary
i -think- most of our bindings in javascript/simplebindings/ aren't of
much use, since they use qscriptvalues, that is another thing that if
it's used is buried pretty deep, all you pass around seems to be a
simple qvariant, so simple thngs like colors,rects,sizes seems to just
work.
yes, i'm not so concerned about simpmle things like colors, etc. but
consistency with things like DataEngines, Services, AddOns, Extensions,
etc. it would be great to avoid having two different ways to, for example,
respond to events such as addonCreated.
yeah, i'll look into reciclyng as much as that code is possible, or at least
doing things that are used in the most similar way possible.
i'm arguing with services right now let's see what i get out of
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Frame applet should give valid message when dropped folder doesn't have any images
On 2010-09-16 11:20:34, Sebastian Kügler wrote: One small issue with i18n context left, otherwise it's good to go in (from my point of view, better wait for annma to mark it as ship it as well). Thanks. I will do it right away :) On 2010-09-16 11:20:34, Sebastian Kügler wrote: trunk/KDE/kdeplasma-addons/applets/frame/picture.cpp, line 88 http://svn.reviewboard.kde.org/r/5362/diff/4/?file=36015#file36015line88 i18n context should be more useful. Anne-Marie Mahfouf wrote: I agree with Sebas, ship it and thanks for looking in this issue! As for the context help for translators, maybe we can put i18nc(Text written on default picture, Dropped folder is empty. Please drop a folder with image(s)); Thanks Anne-Marie :) - Sujith --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5362/#review7637 --- On 2010-09-16 03:54:44, Sujith H wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5362/ --- (Updated 2010-09-16 03:54:44) Review request for Plasma. Summary --- This diff will give the user meaningful message when a folder is dropped to the frame applet and if it doesn't contain image(s). Diffs - trunk/KDE/kdeplasma-addons/applets/frame/picture.h 1174498 trunk/KDE/kdeplasma-addons/applets/frame/picture.cpp 1174498 trunk/KDE/kdeplasma-addons/applets/frame/slideshow.h 1174498 trunk/KDE/kdeplasma-addons/applets/frame/slideshow.cpp 1174498 Diff: http://svn.reviewboard.kde.org/r/5362/diff Testing --- This has been tested. Thanks, Sujith ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML and Plasma - progress()
On Thursday, September 16, 2010, Marco Martin wrote:
On Thursday 16 September 2010, Aaron J. Seigo wrote:
it is not possible to override plasmoid functions in javascript with
things like plasmoid.dataUpdated = function() as far i know, but i
could be wrong, i don't thik we really need this tough.
it's probably avoidable now that we have event listeners and the ability
to connect random functions and objects to signals and what not.
overriding functions in plasmoid is indeed probably avoidable now, but
it will be desirable with other objects.
i found that the following structure looks nice:
in the root element implement a javascript function with the proper name,
like
Item {
function configChangd()
{
do stuff
}
}
and then call it from the appletscript c++ when it's necessary
does the event listener model work? right now in the JS API you can do things
like:
function configChangd() { whatever }
plasmoid.addEventListener(configChanged, configChanged);
then there is some internal bookkeeping around that which keeps hold of the
function passed in and all event listeners are called when that event happens.
prevents the need for any hardcoded when this C++ method is called, call a
method called X in the JS. in fact, if i could go back to the start, i'd use
_only_ event listeners and get rid of the whole plasmoid.functionName =
function ... approach.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Cleanups in pager
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5355/ --- (Updated 2010-09-17 02:29:59.112027) Review request for Plasma. Changes --- Updated diff to latest svn revision. Summary --- * Make configAccepted() just write the new config, and make configChanged() conditionally update the plasmoid after reading the config back in. * Split the grid resizing logic into its own method: recalculateGridSizes(int rows), and make it detect more edge cases. * Rename the main size calculation method to updateSizes(bool allowResize), which will resize the applet to its preferred size if allowResize is true. * Fix a bug which caused applet resizes to be wrongly cancelled in some situations. * Code style cleanups, remove unused variables, etc. (Sorry for putting so many changes into one patch) This addresses bug 250756. https://bugs.kde.org/show_bug.cgi?id=250756 Diffs (updated) - /trunk/KDE/kdebase/workspace/plasma/desktop/applets/pager/pager.h 1176214 /trunk/KDE/kdebase/workspace/plasma/desktop/applets/pager/pager.cpp 1176214 Diff: http://svn.reviewboard.kde.org/r/5355/diff Testing --- Tested configuring the pager from the config interface and the desktop console, and that it responds correctly to changes in desktop count, and in FormFactor and size. Thanks, Anthony ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
