move plasma tools to plasmate

[Alex Fiestas]

On Monday 20 August 2012 01:15:07 Aleix Pol wrote:
> On Fri, Aug 17, 2012 at 5:20 PM, Giorgos Tsiapaliokas
> 
> <terietor at gmail.com> wrote:
> > On 17 August 2012 16:24, Aleix Pol <aleixpol at kde.org> wrote:
> >> Hi,
> >> I don't really see the point of doing that. I don't see why it's
> >> better not to have them in kde-workspace is it troublesome for anyone?
> > 
> > From an aesthetic point of view,
> > 
> > Q: Hello, where are the plasma tools? I want to create a new plasmoid.
> > A: Inside kde-workspace you will find some tools which will make you life
> > easier
> > and in the plasmate repository you will find the plasma ide.
> > 
> > That's why we want to move those tools in plasmate, we want our sdk to be
> > neat. No?
> 
> That's a packaging decision. The Plasmate should depend on the plasma tools.
> > From a technical point of view,
> > those are a few issues for which we have to move the plasma tools inside
> > plasmate,
> > 1. How can someone embed a binary inside a qwidget?
> > Example: How can I embed the binary named plasmoidviewer inside plasmate's
> > MainWindow::CentralContainer::CentralContainer??
> 
> I'm unsure what you mean. You can embed a plasma view. You won't ever
> embed the plasmoidviewer, maybe you can compile the same code twice,
> but it's not the same!
> 
> > 2. Some tools when they are used as standalone applications require a few
> > extra ui stuff.
> > Example: when I execute plasmaremoteinstaller from plasmate I have a known
> > source directory for my plasmoid(thanks to plasmate), but when
> > I execute it as a standalone application I don't., so I need an extra
> > kurlrequester. How can I hide a kurlrequester from a binary?
> 
> Well, you can add arguments to the binary, for example.
> 
> > 3. duplication of code, plasmoidviewer vs plasma-previewer
> 
> You can expose a library.
> 
> > etc...
> > 
> >> In any case, maybe you should put them in a separate repository?
> > 
> > I believe that this is an overkill and also we don't solve the above
> > technical issues.
> > 
> >> Everyone who has been using these tools so far, has done so without
> >> Plasmate, so there's definitely a use case outside Plasmate.
> > 
> > When you say "plasmate" do you refer to the ide named plasmate or the
> > repository?
> 
> The IDE.
> 
> > The plasma tools will be accessible both as standalone applications and as
> > plasmate plugins.
> > 
> > Also those tools aren't a use case outside plasmate. When those tools had
> > been created plasmate didn't exist.
> > Also after the creation of plasmate, the project wasn't really usable, but
> > this has changed by now.
> 
> It's not really what I was saying.
> 
> What I said is that people will keep using Kate, KDevelop, QtCreator,
> emacs, vim or whatever they want to create their plasmoids. You're
> imposing a dependency by neglecting the current users of those tool. I
> think that's generally not good.

I agree with aleix, typical example is Designer and Creator or Assistant.

In the QML area, people are being forced to use Creator because the tools 
aren't exported as a different tool, and that pisses people off (all 
emacs,vim,kdevelop,kate users for instance).

Maybe we need a place where we can put everything workspace development 
related? thinking on:

-Something to tests kio's
-Something to test kded's
-Somethign to test dolphin plugins
-Something to test KRunners (which btw I have been told that there is such 
thing in plasmate iirc but only there).
-Something to test Plasmoids/Dataengines
-More tools to develop those things mentioned before.

I'm of the idea that we should put everything into kdevplatform since it is 
"kdevplatform" after all.

Cheerz !