move plasma tools to plasmate

[Aleix Pol]

On Mon, Aug 20, 2012 at 1:32 AM, Alex Fiestas <afiestas at kde.org> wrote:
> 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 !
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

For one, I wouldn't argue about kdevplatform or kdevelop for the same
reason I said before.

We don't need or want to create a dependency on an application for a
tool. But yeah, we could argue that those should go to kdevelop
because you create plasmoids with it.

Let me summon QtHelp as a good example of how a development technology
can be exported and shared for everyone to take advantage from.

Aleix