Re: RFC: Should our first release depend on Qt 5.3 or not?
+1 2014-05-08 9:25 GMT-03:00 Sebastian Kügler : > On Thursday, May 08, 2014 12:44:29 Martin Klapetek wrote: > > Qt 5.3 is out on 20th May; should we hard depend on it in plasma with the > > first release? > > > > Given we've all been using Qt from git, I think this makes much sense as > > it's well tested with that, as opposed to Qt 5.2.x. > > > > Should the decision be against it, we should checkout Qt 5.2 and start > > testing plasma with that about now. > > > > Your opinions? > > +1 to depend on Qt 5.3. > -- > 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 > -- Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Port PlasmaComponents to use QtQuick Controls where applicable
I agree with Marco, Just would like to remark that building the styles for qtquickcontrols should be top priority. 2013/8/19 Marco Martin > On Monday 19 August 2013, Aaron J. Seigo wrote: > > no matter how wonderful it is to have a single shared implementation > > upstream so we don’t have to do anything but implement applications, we > > have to hit the three points above. > > > > in the end API, stability and device spectrum are what matters to 3rd > party > > developers and our users. > > There are some components that have very minimal change, unfortunately in > many > plasces there is a very small detail (like icon and iconName vs iconSource) > that makes it not zero effort. > Some other are more different, like PageStack got renamed in StackView (but > behaviourally seems pretty much untouched) > > As I said, they are probably in the long term the way to go, should be > possible quite some personalization per se, and if not enough the whole > single > component can still be replaced with a different implementation like we do > now. > > The catch is also that i would really like to see how much lie is the cake > this time (we jumped on promising unfinished technologies by qt several > times > already, and not always ended up very well, remember) > > * is to be tried, for sure, and see if some of the components can be > replaced > with an implementation that is completely drop in. > > * adapting api may be an option, depends how much we want or can suffer (we > have quite on our plate...) > > * plasma style for qtquickcontrols has to be done anyways, since they can > be > used (well, technically at least) from plasmoids and people will use them > (i > guess in the future they may have more widgets, maybe some that we don't > have > in plasmacomponents, so they should play nice together) > > > > -- > Marco Martin > _______ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SocialFeed in 4.10?
+1 Br, Daker Fernandes Pinheiro http://codecereal.blogspot.com 2012/11/7 Artur Souza > On 07/11/2012 11:05, Marco Martin wrote: > >> >> i think the most reasonable way would be aiming to do an independent >> release that can work on top of 4.10, and then aiming for 4.11 >> > > +1 > > Cheers! > > Artur > > __**_ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/**listinfo/plasma-devel<https://mail.kde.org/mailman/listinfo/plasma-devel> > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QActions in QML
2012/10/28 Aleix Pol
> On Mon, Oct 29, 2012 at 1:33 AM, Daker Fernandes Pinheiro
> wrote:
> > Sebas,
> >
> > This just worked:
> > http://paste.kde.org/584660/
> > Where QAction is
> > http://paste.kde.org/584672/
> >
> > Cheers,
> >
> > Daker Fernandes Pinheiro
> > http://codecereal.blogspot.com
> >
> >
> > 2012/10/28 Sebastian Kügler
> >>
> >> On Thursday, October 25, 2012 20:00:25 Aaron J. Seigo wrote:
> >> > not automatically, no. but QActions are QObjects, so you can attach to
> >> > their
> >> > signals in the QML.
> >>
> >> And it's quite wonky, for example offering a list of QActions
> >> (QDeclarativeListProperty or QList, even with the payload casted to
> >> QObjects)
> >> does not seem to work. There's one, corrupt and therefore unusable entry
> >> in
> >> the returned data in the best case, no data at all in the worst.
> >>
> >> A workaround I've found is to send a list of QActions (.name()) in a
> >> QStringList to the runtime, and offer a Q_INVOKABLE QAction*
> >> action(QString);
> >> accessor which returns a QAction* to the runtime.
> >>
> >> Your button has the following:
> >>
> >> property QtObject action
> >>
> >> onClicked: action.trigger()
> >>
> >> Then, in your delegate, you retrieve the action via the key you get in
> >> your
> >> "listmodel":
> >>
> >> delegate: ActionButton {
> >> action: cpppluginthing.action(modelData)
> >> }
> >>
> >> Not the most beautiful thing in the world, but it seems to work at
> least.
> >> I'm
> >> of course open to better solutions.
> >> --
> >> 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
> >
> >
> >
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> >
>
> Wouldn't it be better to qmlRegisterType directly?
>
That's definetely true.
I got this snippet from another project and it re-implemented trigger.
But that's not the case.
>
> Aleix
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
Br,
Daker Fernandes Pinheiro
http://codecereal.blogspot.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QActions in QML
2012/10/29 Marco Martin > On Monday 29 October 2012, Daker Fernandes Pinheiro wrote: > > Sebas, > > > > This just worked: > > http://paste.kde.org/584660/ > > Where QAction is > > http://paste.kde.org/584672/ > > > > Cheers, > > > > Daker Fernandes Pinheiro > > http://codecereal.blogspot.com > > > > isn't QAction already registered as "action" primitive type? > At least not on QtQuick 1.1 > > -- > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > Br, Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QActions in QML
Sebas,
This just worked:
http://paste.kde.org/584660/
Where QAction is
http://paste.kde.org/584672/
Cheers,
Daker Fernandes Pinheiro
http://codecereal.blogspot.com
2012/10/28 Sebastian Kügler
> On Thursday, October 25, 2012 20:00:25 Aaron J. Seigo wrote:
> > not automatically, no. but QActions are QObjects, so you can attach to
> their
> > signals in the QML.
>
> And it's quite wonky, for example offering a list of QActions
> (QDeclarativeListProperty or QList, even with the payload casted to
> QObjects)
> does not seem to work. There's one, corrupt and therefore unusable entry in
> the returned data in the best case, no data at all in the worst.
>
> A workaround I've found is to send a list of QActions (.name()) in a
> QStringList to the runtime, and offer a Q_INVOKABLE QAction*
> action(QString);
> accessor which returns a QAction* to the runtime.
>
> Your button has the following:
>
> property QtObject action
>
> onClicked: action.trigger()
>
> Then, in your delegate, you retrieve the action via the key you get in your
> "listmodel":
>
> delegate: ActionButton {
> action: cpppluginthing.action(modelData)
> }
>
> Not the most beautiful thing in the world, but it seems to work at least.
> I'm
> of course open to better solutions.
> --
> 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
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Doxygen for QML components
2012/10/17 Marco Martin > On Wednesday 17 October 2012, Aurélien Gâteau wrote: > > An interesting bonus point of this annotation is that it could be used to > > provide more precise information about the type. For example a property > > which takes a QtObject but actually expects a model could be marked as > > such: > > > > property QtObject model // doxyqml: type=QAbstractItemModel > This is good enough. > > > > Are you OK with me following up with maintainers of api.kde.org so that > > doxyqml is used to generate documentation there? > > yeah, fine for me > > > -- > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Trigger KRunner on top screenedge
Hi, 2012/10/3 Martin Gräßlin > Hi all, > > just wanted some feedback on an idea I got today. What about binding the > showing of KRunner on hitting the top screen edge? > Good idea. However, I think it would clash for users who uses the panel on top. Especially with the auto-hide option. > > Given that KRunner slides in from the top edge it would end up in a neat > functionality, throw the cursor against the edge and down comes KRunner. > Maybe > even centered at the cursor position? > > I don't think that the top screen edge would conflict with anything else. > When > using for quick-maximization of maximized windows the action would not be > triggered anyway and for grabbing a maximized window to move it away it > would > not matter either as you have to push against the edge. > > So opinions? Should I add support for that in KWin? It's pretty trivial :-) > > Cheers > Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Button component width
2012/10/3 Marco Martin > On Wednesday 03 October 2012, Aleix Pol wrote: > > Hi Plasma! > > I've been trying to figure out why buttons had a weirdly big size by > > default, forcing me to set a random width that will be rarely appropriate > > when translating. > > > > I decided to look into the code and that's what I found [1]. There I can > > that code is a bit old btw, i changed it today using implicitsize instead > of > paintedwidth to decide text elide when necessary > > > see that we are getting the max between the size we want and > > theme.defaultFont.mSize.width*12 which looks totally random to me. Maybe > we > > can just remove this part? Or at least leave it to 1 m so that it's never > > 0? > It think is better having a usable default size policy. Having 1 pixel or not visible buttons doesn't look a good idea for me. > > > > it's a reasonable size espressed in characters (policy i unfortunately > still > didn't make clear enough there is that pixel sizes should be avoided as > much > as possible). > ideally, width and height of buttons or similar elements should never be > specified by the code that uses them, but alwas stay the default, that is > implicitWidth/height. > > 12 characters is a reasonable default width for a button (and the sane > length > a button text should have), what should be done is to gather all those > sizes > in a single private file so they are consistent among different widgets > > In this case it's not straightforward putting in a separated file, because this length needs the Button's font info. Unless we set a different policy. > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > Br, Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml version of visibility gone
Hi! You could use a Row <http://qt-project.org/doc/qt-4.8/qml-row.html> element and play with the visibilities as you are describing. Cheers, Daker Fernandes Pinheiro http://codecereal.blogspot.com 2012/9/8 Reza Shah > Hi, > > Background: > I have two buttons with display order side by side: [A][B] > I like to have the final display like [B] > > In android i can set the visibility of button A to gone, then the B > will occupy button A space. > > I tried to achieve the same thing in qml using anchor. > So when A visibility is false, i set button B left anchor to parent.left. > Is this correct way? or there is better alternative? > > > Regards, > Reza > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: move plasma tools to plasmate
2012/8/16 Sebastian Kügler > Hey, > > First of all: if anybody objects to having these tools (plasmoidviewer, > etc.) > not shipped with kde-workspace anymore, speak now or forever hold your > peace. > :) > Agreed. > > On Monday, August 13, 2012 17:40:39 Giorgos Tsiapaliokas wrote: > > my GSoC tasks included to move the plasma tools(those are > > kde-workspace/plasma/generic/tools) into plasmate. > > In order to do that I will use the "git subtree" command. > > > > With git subtree I will make a copy of kde-workspace/plasma/generic/tools > > into plasmate and then > > I will remove with git rm kde-workspace/plasma/generic/tools. The "git > > rm kde-workspace/plasma/generic/tools" > > will have to be done in every wanted branch of the kde-workspace > repository. > > I believe that those branches should be > > > > (in short those are the master and the personal branches, I didn't > > include all those who start with KDE/4.x and Active/*) > > origin/master > > We need to only remove the tools from master, the rest are branches that > should either not be touched anymore (in this way), or are personal > branches > which are maintained (i.e. merged / rebased, etc.) by their owners. > > > origin/amourphiouskb > > origin/apol/qmlrunner > > origin/belem/Active/1.0 > > origin/dafre/new-powerdevil > > origin/focus > > origin/hpereira/oxygen-shadows > > origin/ivan/activity-window-rule > > origin/kdepim/enterprise-4.0.83 > > origin/kdepim/enterprise-4.1 > > origin/kdepim/enterprise-4.2 > > origin/kdm-plasma > > origin/kickoff-qml > > origin/ksmserver/qml-shutdowndlg > > origin/kwin-wayland > > origin/kwin/mart/tabboxFixes > > origin/libplasma2 > > origin/master > > origin/oxygen/background-pixmap > > origin/oxygen/extended-splitters > > origin/plasma/bookmarksrunner-chrome-gulino > > origin/plasma/iwesp/quicklaunch > > origin/plasma/keyboard_applet_svgtext/mart > > origin/plasma/luisgabriellima/pager-qml > > origin/plasma/mart/declarativeWidgetsExplorer > > origin/plasma/mart/wac-appletscript > > origin/plasma/sreich/applet/hdd-activity > > origin/plasma/sreich/plasmasvgviewer > > origin/plasma/sreich/plasmoidviewer-use-kpart > > origin/plasma/sreich/qml2-system-monitors > > origin/plasma/sreich/sal-lenses > > origin/plasma/sreich/sal-qml > > origin/plasma/sreich/tasks-qml > > origin/plasma/viranch/analogclock > > origin/plasma/viranch/powermanagementservices> > > origin/plasma/viranch/tasks > > origin/qt3support > > origin/screenlocker > > origin/sebas/active-lock-splash > > > > also before the merge I would like to merge the branch > > named plasma/sreich/plasmasvgviewer into master. > > This branch doesn't look ready for primetime, it probably needs more > polishing. > > > If you have any branches which have commits in plasma tools please let me > > know in order to move them to > > plasmate. > > Not necessary. :) > > 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 > Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PlasmaComponents ScrollBar is broken
Hi Aleix, I'll take a look a creafull look this night. Cheers, Daker Fernandes Pinheiro 2012/7/30 Marco Martin > On Monday 30 July 2012, Aleix Pol wrote: > > Hi, > > I've been trying to get two applications to work properly that use the > > PlasmaComponents: the QuickChat plasmoid (ktp-text-ui) and muon > > discover. On both of them I've had big problems while using Flickable > > elements programatically (that is, playing with the contentY property) > > while having a scrollbar. Note that the test case attached works > > without a scrollbar, but with the scrollbar it starts to do weird > > stuff. > > > > I've been looking through the code, and to me it seems like the > > RangeModel is messing the whole implementations. There are two > > important properties there value and position. And changing any of > > those make the other change so we enter quite some big loops of > > changes that are a bit annoying. > > > > I've been thinking of rewriting the ScrollBar without this RangeModel, > > but maybe that's only because I don't understand it enough. Can > > anybody look into this and give me a hand? I think it would be really > > interesting to sort this one out! > > > > Aleix > > yep, i see the binding loops, i can look into it. (daker, are you still > there? > ;) > > are you experiencing also problems in the behavior? the testcase seems to > behave fine here > > -- > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML plasmoid, pageStack.pop() doesn't work
Hi Gao,
Actually the initialPage property holds 'the' initial page.
It doesn't works with an ordered lists of pages.
Just put initialPage: c to get your expected behaviour.
Br,
Daker Fernandes Pinheiro
2012/7/12 Gao Xiang
> The sample qml is easy:
> ==
> import QtQuick 1.1
> import org.kde.plasma.components 0.1 as PlasmaComponents
> Item {
> PlasmaComponents.PageStack {
> id: pageStack
> anchors.fill: parent
> initialPage: [ c, b, a ]
> }
> PlasmaComponents.Page {
> id: a
> anchors.fill: parent
> PlasmaComponents.Label{ text: "a" }
> onStatusChanged:
> if(status==PlasmaComponents.PageStatus.Active)
> pageStack.pop();
> }
> PlasmaComponents.Page {
> id: b
> anchors.fill: parent
> PlasmaComponents.Label{ text: "b" }
> onStatusChanged:
> if(status==PlasmaComponents.PageStatus.Active)
> pageStack.pop();
> }
> PlasmaComponents.Page {
> id: c
> anchors.fill: parent
> PlasmaComponents.Label{ text: "c" }
> }
> }
> ==
> I wish to get a "c" in screen. But I got a "b". What's wrong? Why the
> second pageStack.pop() doesn't work?
>
> Thanks.
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Theming, again
Hi, 2012/6/4 Marco Martin > On Monday 04 June 2012, Ivan Čukić wrote: > > Hi all, > > > > With qml-ifying plasma, we have the opportunity to completely break > > the current theming system and make something that would work. I'm > > well, not really, since svg and framesvg are directly binded to qml (and > quite > heavily used, even outside of components) so current qml stuff already has > a > pretty heavy dependence on it, at least the api part of it (would be > possible > to maintain 100% compatibility of current qml code if the api of > framesvgitem > is kept even using a different backend). > Maintaining compatibility with SVG wouldn't be hard. It would be needed a QML Style that could handle SVGs as Themes. > > > usually all for back-compatibility, but in this case I think we should > > start from scratch. We have already had discussions about why the > > current theming system is not sufficient, so I'm not going to repeat > > them. > > > > With the plans [1] for QML themes, we'll get a proper theming for > > Plasma widgets, the thing that will remain is to do the same for > > applets, panels and similar. > > desktop widgets will have (at least i hope) be painted with qstyle, for > retrocompatibility, is still not really clear what are the plans for > something > Exactly, the QStyle painting will be there for retro compatibility and implementing new styles with QML are possible, but the goal is opening doors for Styles written in QML or C++ QtQuick. > different from qstyle, that post seems still deep in the investigative > phase > (Daker, any news/updates about that?) > It's important to notice that currently it's a separated project from Qt Desktop Components. Our intention is to join both efforts and this will be under discussion at QtCS. I hope that something good comes out from it. > > as i said, my main concern is that framesvg is used a lot around in qml, so > that would require again a new porting effort. > In the proposed architecture [2], the porting effort wouldn't be much painful, at least for the Plasma Components. Please let me know what else we could make themable. It would require removing the interaction code from the Plasma Components and transforming it into a Style. Obviously, this simplification of the Plasma Components would add these desktop components dependecy on Plasma. > > ignoring that for a moment, what i would like is: > * still workspace look different at least potentially from the app look, > even > if just a different default theme > * themes completely pixmap/svg//graphics based, no code involved, not even > qml > This would be perfectly covered. We are also carrying on with the project what we call CustomStyles. This styles set is a helper for creating styles using pixmap/svg/graphics. * for sure nothing based on qstyle ;) Surely not. :-) > > as capabilities, overall i like framesvg (way, way more powerful than > BorderImage that i quite dislike), speaking of not retrocompatible > changes.. > there are things that revealed to be pretty painful, like having to have > the > borders actually splitted in different elements rather than split the > rendered > pixmap afterwards, having to design the thing from scratch i would make it > behave in a radically different way. > > main concern is mostly performance on scene-graph since it would have to > be a > QQuickPaintedItem, meaning resize the svg, paint it in software on a > texture, > and upload the new texture every time, but there could be no way around it, > any way is chosen in the end. That's true. But enabling themes/styles in QML can makes them free from QQPI for new styles that can be written. > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > [2] http://codecereal.blogspot.com.br/2012/04/qml-themingstyling.html Br, Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Next Iteration Sprint, confirmed !
On 04/20/2012 11:33 AM, Dario Freddi wrote: Il 20 aprile 2012 15:40, Martin Gräßlin ha scritto: On Friday 20 April 2012 15:19:14 Alex Fiestas wrote: On Friday, April 20, 2012 02:20:58 PM Marco Martin wrote: I expressed my concerns before, i'll do it again: i think this is really not the time to do it, any good intention and vision is not much use if there is not the technical foundation being layd down, and at the moment there isn't. i would see this useful a year from now, not now (maybe if the goal was 80% programming 20% talking things would be a bit different). maybe i'm wrong but i'm feeling it's a waste right now. anyways good luck with it, i hope i'll be proved wrong. I'm no expert, but the vision should NOT be driven by technology but instead the other way around, once we have the vision and we have the solution to implement that vision, then we will have to care about what technology we have to create/adapt/adopt/etc. Of course since we are developers we will be doing technical work before vision/solution is finished. +1000 - I think that is really important to first get what we want to achieve and afterwards work on the technology side to get it implemented. And that's a good reason to have the sprint *now* before we have libplasma2 and before we have ported to Wayland. I agree 100% with Alex and Martin, and I'll even dare to say that coding without planning and without a defined goal is a long standing mistake in our workflow which we are trying to fix with this sprint.. Paradoxically, it's exactly *BECAUSE* we need to (re)build a foundation that we need to plan a vision. Once you have a well defined platform, your vision will be of course limited to what the platform can offer. OTOH, this time we have to do things right and start planning everything from the beginning, which eventually means having the platform built around and for our vision, and not the other way round. I also agree that the vision must be over the limitations, specially when the concern is how to prioritize the development. Btw I am quite confident that the ideas which will come up will have no impact at all on the current Plasma codebase. What's possible right now can be implemented with QML 1 and everything else just has to wait. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Cheers, -- Daker Fernandes Pinheiro http://codecereal.blogspot.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qtcomponents documentation
Giorgos, If so, is best to do before the sprint. Cheers, On Sunday, December 18, 2011 05:40:26 AM Giorgos Tsiapaliwkas wrote: > I am in. > > When me and Daker were writing the doc we didn't pay any attention to > the coding style. > Those days the plan was to write the doc with mediawiki format. Is the > plan the same?? > If yes, I can reform the coding style. -- Daker Fernandes Pinheiro openBossa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qtcomponents documentation
Sounds like a good plan. Daker Fernandes Pinheiro 2011/12/17 Aaron J. Seigo > On Saturday, December 17, 2011 18:11:06 Marco Martin wrote: > > On Saturday 17 December 2011, Aaron J. Seigo wrote: > > > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote: > > > > Hi all, > > > > > > > > I think we should do a real documentation sprint for the plasma > > > > qtcomponents, to have a good api doc for the 4.8 release. > > > > > > and ideas / preferences on when and where? > > > > well, was actually more thinking about an irc meeting, kinda like > bugdays, > > next week (or after the christmasy things if better for people) > > perhaps set up a doodle for people to register their preferred times and > then > we can promote it on our blogs? > > -- > Aaron J. Seigo > humru othro a kohnu se > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 > > KDE core developer sponsored by Qt Development Frameworks > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qtcomponents documentation
That's fine for me. Marco, I'm still working on the branch, should I submit the changes into it or directly in master? Cheers, On Saturday, December 17, 2011 02:11:06 PM Marco Martin wrote: > On Saturday 17 December 2011, Aaron J. Seigo wrote: > > On Saturday, December 17, 2011 13:39:05 Marco Martin wrote: > > > Hi all, > > > > > > I think we should do a real documentation sprint for the plasma > > > qtcomponents, to have a good api doc for the 4.8 release. > > > > and ideas / preferences on when and where? > > well, was actually more thinking about an irc meeting, kinda like bugdays, > next week (or after the christmasy things if better for people) > > to get all documented and at least a tutorial with pretty pictures on the > wiki -- Daker Fernandes Pinheiro openBossa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Introducing components, how to
On Wednesday, November 09, 2011 03:31:46 PM Marco Martin wrote: > Hi all, > > there is still some work to do, but the components are almost done in their > final structure (good for the upoming freeze, ehehe :) > > components are imported with: > import org.kde.plasma.components > > regardless of the platform we're in. > > We have at the moment 37 widgets in the touch profile, 35 in the normal > one, tried to follow the standard api as much as possible even tough with > some little deviations (especially where it was too unbearably ugly :p) > > As for documentation, of course any help will always be welcome :p The plasma components documentation work is happening on remotes/origin/plasma-components-doc branch. > > > If you are writing an application, just use kdeclarative, and the proper > import paths will be setted. > > to see what component is available, just take a look at the qmldir file in > the source directory of kde-runtime > kde-runtime/plasma/declarativeimports/plasmacomponents/qml/ > or > kde- > runtime/plasma/declarativeimports/plasmacomponents/platformcomponents/touch > / > > now, two things: > Q: why checking qmldir? > A: not all files are available, the ones not shown there are private api > > Q: what are those two folders? > A: hardware specific components: > > the plasma QtComponents are targeted to two things: > * Plasma Desktop widgets > * Plasma Active widgets and applications > > (for desktop applications, we can only wait to see whatever it happens with > desktop components but is way too early to know ;) > > When writing a widget, an application etc, just use > import org.kde.plasma.components, the proper one is decided by the > kdeclarativerc file, if it has > [Components-platform] > name=touch > > for packagers: in plasma active among the default files this kdeclarativerc > has to be installed > > the imports in platformcomponents/touch will override the standard one, > actually giving a series of touch optimized widgets. > > only a few that needed have different implementations, the other ones are > duplicated by being installed 2 times by cmake > > some of the differences: > * Buttons and lineedits don't have mouseover effects > * by default scrollbars behave like scroll decorators on touch > * scrolldecorators are installed only on touch (provided just for > compatibility, use scrollbar instead, it behaves the right way(tm) ;)) > * sectionscroller looks like the iphone addressbook scroller on touch, like > a scrollbar on desktop > * Window is *not* provided on desktop: in desktop widgets makes really no > sense > * QueryDialog uses a KDialog on desktop, on touch uses qml items and is in > a Plasma::Dialog > * the same way, Menu/ContextMenu is a QMenu on desktop, while is a more > plasma looking thing on touch > > > this architecture is going to be final once released in 4.8 (at least until > frameworks5), so "speak now or forever shut up" :p > > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel Cheers, -- Daker Fernandes Pinheiro openBossa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PlasmaComponents.Button missing feature: use system icons!
I think we should have a declarative image provider for getting icons. In this
way we should just do something like:
Button {
icon: "image://kde/desiredIcon"
}
What do you think?
Cheers,
On Monday, October 31, 2011 07:27:14 AM Marco Martin wrote:
> On Monday 31 October 2011, Aaron J. Seigo wrote:
> > On Monday, October 31, 2011 10:12:57 Marco Martin wrote:
> > > when is not an applet (ie just qmlviewer, or qml packages), a package
> > > may or may not be there
> >
> > this is one of the things i really, really liked about how Packages are
> > implemented in the Javascript API. anything can register a Package at a
> > given place in the Context hierarchy, and then such searches simply scan
> > the Context stack for Packages, checking each along the way.
> >
> > it's elegant, extensible and future proof.
> >
> > too bad the people working on QML (and as i understand, V8 as well which
> > lacks the concept of a context stack in its implementation?) "know
> > better" so we'll likely lose this in future. straight from the
> > "amazingly disapointing" files.
>
> yeap, that's one of the reasons i'm quite hesitant doing any new work on
> the qscriptengine right now.
>
> what could be tried, afaik on the public c++ side qml2 shouldn't change
> much, so the qdeclarativecontext should still exist (their implementation
> of context that no, isn't *exactly* a context of the qscriptengine :p)
>
> so we could register there a qobject with id "package", so any reference to
> package in child objects would go to that one
>
> Cheers,
> Marco Martin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
--
Daker Fernandes Pinheiro
openBossa
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: merging declarative plasmoids
In QtQuick 1.1 there are the implicitWidth and implicitHeight properties. Cheers, Daker Fernandes Pinheiro 2011/9/14 Marco Martin > On Wednesday 14 September 2011, Aaron J. Seigo wrote: > > On Tuesday, September 13, 2011 20:39:20 Viranch Mehta wrote: > > > Also, I would like to make a note here that battery monitor and > > > lock/logout > > > > speaking of lock/logout and applets which are essentially rows of icons > ... > > has someone worked out the issues around QML widgets not have size hints > > and appropriate sizing of applets like lock/logout in panels in > > plasma-desktop? > > yep, the slc applet should have correct sizing now. > unfortunately it requires some manual calculation from the qml side since > is > not something offered stock, but if the root element offers "minimumWidth" > and > "minimumHeight" the applet will use them as minimum size hints. > > in plasma2, in the case of a scene that doesn't have qgraphicswidgets in > the > middle, sizing of things should be a bit easier and a tad more automatic > (just > remains pretty hard do to expanding things like the taskbar) > > Viranch, that should be done for the lock/logout applet as well > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma QML scrollbar
2011/8/10 Nuno Pinheiro
> **
>
> A Quarta, 10 de Agosto de 2011 06:08:56 Shaun Reich você escreveu:
>
> > How can I get a scrollbar, preferably one that fades away when not
>
> > needed and such, to be displayed in qml?
>
> >
>
> > Does the QML components gsoc touch on that?
>
The ScrollBar component has exactly this behaviour.
I'm still working on a separated branch (plasma/declarative) in kde-runtime.
But I will do a merge and a documentation release until next week's end.
Until there you can get the component from my branch and use it in your
project.
Shouldn't be hard to change it later, because it will only require you to
add a proper import.
In the same branch at plasma/declarativeimports/tests/gallery you will find
examples of usage of the current components.
> >
>
> > I ask because I had an urge to port the {konq, konsole, kate} session
>
> > applets to QML.
>
> >
>
> > So I did that tonight, so far the konsole one works quite well -- but
>
> > I'm in need of a scrollbar for the listview.
>
> >
>
> > (since obviously when you have a large number of items, you can't just
>
> > flick everywhere.)
>
>
> if you have the size of what ever you are scroling and can control the
> actula position of it, making a scroolbar should be rather trivial.
>
>
>
>
> --
>
> Nuno Pinheiro | nuno.pinhe...@kdab.com | UI Designer
>
> Klarälvdalens Datakonsult AB, a KDAB Group company
>
> KDAB - Qt Experts - Platform-independent software solutions
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
> Happy hacking,
Daker Fernandes Pinheiro
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
