Re: Files, config, and welcome (again)
Hi there, Thanks for all the answers, I was travelling and couldn't get back on this sooner. Dnia niedziela, 15 kwietnia 2012 o 10:14:13 Djuro Drljaca napisał(a): > as far as I know it is very important to know where you tested it. > If you only tested it in the plasmoidveiwer then this is probably > the reason it doesn't work. Install the plasmoid on the system and > try it there ... then I think it probably will work. Yes, you were right. Indeed, when added to the plasma desktop the config does work. Thanks! Dnia niedziela, 15 kwietnia 2012 o 18:22:52 Mark napisał(a): > If you're making a qml only plasmoid then KCal is not possible > since it doesn't have a qml binding (as far as I know...). Well, I am trying to stick with QML/JS. I have absolutely no experience with C++ and learning it just to write a plasmoid seems an overkill... Dnia niedziela, 15 kwietnia 2012 o 18:45:11 Kevin Krammer napisał(a): > In either case using KDE's todo classes is certainly the right way > to go, since it will allow the applet to show/edit data created by > other todo/task handling applications such as KOrganizer or > Zanshin (http://zanshin.kde.org/) Zanshin looks great, thanks for the info. And yes, using something that would talk with the Calendar seems a great idea. Problem is, I cannot find any documentation on doing that in QML/JS. > The Kontact touch related directories in kdepim could be helpful > here, i.e. those are QML based user interfaces for components that > are traditionally part of the Kontact suite. Where can I find those. > Since Todos/Tasks are another subtype of calendar entry (like > event) some of the calendar Plasma integration points might be a > good start as well. Any link? Can't find that anywhere. Dnia czwartek, 19 kwietnia 2012 o 18:32:06 Anton Kreuzkamp napisał(a): > Just read your notes on what it should be able to do. I don't know > what the akonadi-kcal-solution is able to do. Probably not quite > everything you want... O..k. Any docs on it? > I recommend you to get in touch with the kdepim-gurus and get to > know what it is able to do and eventually (ideally) how to get the > missing parts inside akonadi directly, as this is where it > belongs. Thanks, will try. > PS: that means I can delete one item from my todo-list, which is > "Create Akonadi-based Todo-Plasmoid". Yay! :) Hey, I haven't done it yet! ;) -- Pozdrawiam Michał "rysiek" Woźniak Fundacja Wolnego i Otwartego Oprogramowania 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: Re: Re: Next Iteration Sprint, confirmed !
+1 to what Martin Gräßlin said though in my case I want to see the current stuff ported to QML so we can support the current shell in the future, it has a lot of advantages I'd like to keep. On Monday, April 23, 2012 05:42:42 PM Martin Gräßlin wrote: > My expectation from the sprint is that we will figure out a new interaction > of the shell and windowing system which is not possible at the moment. I'd like to share my expectations as well. I expect to come out from the sprint with a strong group of people joined by a vision, the kind of team we can find in Solid/Frameworks/Sysadmin/Web/etc where everybody is ready to go the extra mile if needed. Personally I don't care so much about the new shell, but rather in everything else, I'm interested in stuff like base applications, systemsettings, hardware support (how to interact with hardware) and "KDE as an OS" (yes I said that). I'm sure that each person attending to the sprint has different interests (I can imagine the ones for notmart :p) and that is perfect for making it a success. Cheers ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Next Iteration Sprint, confirmed !
Il 23 aprile 2012 17:42, Martin Gräßlin ha scritto: > On Monday 23 April 2012 13:03:56 Marco Martin wrote: >> On Monday 23 April 2012, Sebastian Kügler wrote: >> > Or put simply: Homework first. >> > >> > Now if the sprint would be: let's take two days to reflect on the current >> > state and define where we want to go, and then take 5 days to sit down and >> > clear the road for getting there, that would be an approach I'd be a lot >> > more happy with. >> >> yep, +1000 >> couldn't have said it better. >> it's a matter of responsibility > I really don't see your concerns and I will explain why although I never > intended to write that down in a public mailing list (out of fear some media > would discover it). > > My expectation from the sprint is that we will figure out a new interaction of > the shell and windowing system which is not possible at the moment. We have > pretty much reached what's possible with Plasma tells KWin what to do. But > turning it around (Plasma becomes a plugin to KWin) will give us complete new > possibilities which I will start to explore as soon as we are in feature > freeze. > > The result of the sprint will therefore be: > 1. Existing Shell is not touched > 2. A new Shell needs to be implemented > > This allows us to have some basic new requirements: > 1. QML2 only > 2. Qt5/KF5 only > 3. libplasma2 only > 4. Compositing only > (5. Wayland only?) > > Basically we can cut off the legacy world and completely concentrate on > pushing libplasma2 to support the new shell. After that is done, we will be > able to port the existing shell to libplasma2/QML2. > > So my expectation is that it will have the exact opposite effect of what you > fear. By turning libplasma2 into a requirement for any new work we force our > workspace developers to work on it. But we need the vision, the clear goal to > motivate everyone. > > First thinking we need to transit the complete existing shell is probably no > motivating factor to do boring stuff as libplasma2. We need the stick and the > carrot here. The new shell will be the carrot, the requirement for it has to > be libplasma2 the stick. > > Last remaining note: it's also the best for our users as it will continue on > our trusted and well known and stable Qt4/kdelibs4 code base :-) ^ all of this. > > 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
Re: Re: Next Iteration Sprint, confirmed !
On Monday, April 23, 2012 02:33:45 PM Sebastian Kügler wrote: > Addressing these two concerns individually: > > On Friday, April 20, 2012 15:19:14 Alex Fiestas wrote: > > 1-Everybody joings libplasma2 development, coordination is a mess, lot of > > new people working in old code etc, not ideal. > > I don't see why this would happen, we just need to coordinate and talk to > each other. This kind of coordination is something we do all the time. :) Considering the type and the amount of work that will have to be done in libplasma the only close example imho is the entire Frameworks5 thing, and libplasma2 is included in it anyway. So no, this is not something we do all the time. > I'd really like to avoid some kind of consumer view onto Plasma. Not sure what do you mean here. > Getting > involved at this level also means moving its foundations forward, it's part > of our shared responsibility that keeps Plasma alive (and prevents the > "maybe in the future nobody cares" problem from arising). The same goes, > btw, if you replace libplasma2 with Frameworks5 and "Plasma" with "KDE" -- > those are in fact closely related. Well, just speaking for myself, plasma2 at the moment is NOT my responsability, mines are: solid, libsolid, BlueDevil, RandR, Kamoso, and Frameworks5 (though I haven't done anything yet), libplasma2 is not one of them. That doesn't mean that I won't work on libplasma2 and QML effort porting for the greater good, but they are not my responsability just right now, they will be int he future (I guess). Anyway, all this rambling is precisely what we want to avoid by not talking technical stuff in the Vision sprint, and I don't see the hurry on talking about technical stuff just yet because stuff will be done, work will be done, and libplasma will be moved forward that is for sure since we want to keep compatibility with the current stuff, just this sprint is not the place or the time to discuss it. I have heard normart saying "What I want to do is a core plasma sprint to make libplasma2 happen", what about doing that instead ? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Next Iteration Sprint, confirmed !
On Monday 23 April 2012 13:03:56 Marco Martin wrote: > On Monday 23 April 2012, Sebastian Kügler wrote: > > Or put simply: Homework first. > > > > Now if the sprint would be: let's take two days to reflect on the current > > state and define where we want to go, and then take 5 days to sit down and > > clear the road for getting there, that would be an approach I'd be a lot > > more happy with. > > yep, +1000 > couldn't have said it better. > it's a matter of responsibility I really don't see your concerns and I will explain why although I never intended to write that down in a public mailing list (out of fear some media would discover it). My expectation from the sprint is that we will figure out a new interaction of the shell and windowing system which is not possible at the moment. We have pretty much reached what's possible with Plasma tells KWin what to do. But turning it around (Plasma becomes a plugin to KWin) will give us complete new possibilities which I will start to explore as soon as we are in feature freeze. The result of the sprint will therefore be: 1. Existing Shell is not touched 2. A new Shell needs to be implemented This allows us to have some basic new requirements: 1. QML2 only 2. Qt5/KF5 only 3. libplasma2 only 4. Compositing only (5. Wayland only?) Basically we can cut off the legacy world and completely concentrate on pushing libplasma2 to support the new shell. After that is done, we will be able to port the existing shell to libplasma2/QML2. So my expectation is that it will have the exact opposite effect of what you fear. By turning libplasma2 into a requirement for any new work we force our workspace developers to work on it. But we need the vision, the clear goal to motivate everyone. First thinking we need to transit the complete existing shell is probably no motivating factor to do boring stuff as libplasma2. We need the stick and the carrot here. The new shell will be the carrot, the requirement for it has to be libplasma2 the stick. Last remaining note: it's also the best for our users as it will continue on our trusted and well known and stable Qt4/kdelibs4 code base :-) Cheers Martin 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: Plasma Components and Dialog Focus
On Friday 20 April 2012 00:41:39 you wrote: > On Wednesday 18 April 2012 19:37:58 Marco Martin wrote: > > On Wednesday 18 April 2012, Aleix Pol wrote: > > > Hi, > > > I've been using Plasma Components' Dialog element in a couple of > > > projects > > > and I have the same problem on both. > > > > > > Whenever I show a dialog (by visible=true) I don't get the keyboard > > > focus > > > on it, not even by calling the activateWidget() method. Am I doing > > > anything wrong? Is there any plan to fix this? > > > > > > It's quite an important issue, specially on the Quick Chat plasmoid. > > > > Dialog in components or in core? (two different things) > > > > do you know if the actual window has the focus, or if is something related > > to theparticular declarativeitem that should have it? > > Quick Chat is Plasma Core's, but on both the behavior is the same. I have a > button to display the dialog. I click on it. Then if I press space, I can > see the button underneath being pressed, which means that the focus is > still on the parent window. > > Aleix Bump. Please don't forget about this issue, I think it's important. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Next Iteration Sprint, confirmed !
Addressing these two concerns individually: On Friday, April 20, 2012 15:19:14 Alex Fiestas wrote: > 1-Everybody joings libplasma2 development, coordination is a mess, lot of > new people working in old code etc, not ideal. I don't see why this would happen, we just need to coordinate and talk to each other. This kind of coordination is something we do all the time. :) > 2-We wait until libplasma2 is done, maybe when it is done we don't have > this much interested people anymore. By waiting until it's done, it won't get done. Doing this work doesn't mean that all other work is blocked or has to stall, in fact especially the QML ports already allow for quite visible improvements in our user experience, and bringing interesting new features and Look and Feel on top of our currently stable base. The earlier we get libplasma2 done, the better since it allows us to move forward at a much quicker pace again, it's the sort of foundational work that is needed once in a while, and really would help to get Plasma in all its disguises to the next level. I'd really like to avoid some kind of consumer view onto Plasma. Getting involved at this level also means moving its foundations forward, it's part of our shared responsibility that keeps Plasma alive (and prevents the "maybe in the future nobody cares" problem from arising). The same goes, btw, if you replace libplasma2 with Frameworks5 and "Plasma" with "KDE" -- those are in fact closely related. 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: Next Iteration Sprint, confirmed !
On Monday 23 April 2012, Sebastian Kügler wrote: > Or put simply: Homework first. > > Now if the sprint would be: let's take two days to reflect on the current > state and define where we want to go, and then take 5 days to sit down and > clear the road for getting there, that would be an approach I'd be a lot > more happy with. yep, +1000 couldn't have said it better. it's a matter of responsibility Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Next Iteration Sprint, confirmed !
On Friday, April 20, 2012 15:39:02 Daker Fernandes Pinheiro wrote:
> I also agree that the vision must be over the limitations, specially
> when the concern is how to prioritize the development.
In principle, basing development of technology onto a vision is the correct
approach. There's a big but ("Big Butt?" ;)) here, though. We already know
that, in order to move forward, two things need to be done, which are dictated
by "external requirements", rather than the requirements of the workspace
itself, those are:
- Moving our existing codebase to QML
- Make libplasma2 happen
The reasons are:
- If we don't move all of our plasmoids to QML, we'll not be able to take
advantage of SceneGraph
- Any advantages that Qt5 could bring us will be blocked
- If we don't work on libplasma2, Frameworks5 will not happen, we have a
community-responsibility to do our part here
Those cannot be dismissed as "technology before vision" because we already
have identified these things as crucial to move on with our vision. Now it's
easy to ignore all these efforts by just starting a new process of finding a
vision (and my impression so far is that we're running into this trap), but I
think that's very wrong, and disrespectful to those who have been working on
it.
I think to new members of the workspace team, tackling these two areas would
be very good starting points to get into core workspace development -- because
that has to happen in tandem with the rest of the team, not in parallel. This
could also help with a notorious manpower problem we have when it comes to
working on Plasma Core issues, especially libplasma2.
Or put simply: Homework first.
Now if the sprint would be: let's take two days to reflect on the current
state and define where we want to go, and then take 5 days to sit down and
clear the road for getting there, that would be an approach I'd be a lot more
happy with.
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: MPRIS2 dataengine
On Sunday, April 22, 2012 01:00:27 Alex Merry wrote: > Eike Hein suggested that mpris2 should go into kde-workspace, next to > nowplaying, to allow widget authors to port away from nowplaying. (The > trouble with putting mpris2 in addons is that there would be an > incentive - ubiquity - for widget authors to continue to use > nowplaying). In 5.0, nowplaying can be ditched, and mpris2 can move to > addons, if that's a more sensible place for it long-term. Sounds like a good plan. Maybe we should put some deprecation warning into the engine as well, probably as kWarning() on load, so it shows it to developers, but doesn't clutter the log. -- 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
