From kde-panel-devel  Sat Feb 27 18:25:40 2010
From: Richard Dale <richard.j.dale () gmail ! com>
Date: Sat, 27 Feb 2010 18:25:40 +0000
To: kde-panel-devel
Subject: Re: Plasma/PopupApplet and Plasma::PackageStructure
Message-Id: <491684421002271025r290c2f31ye9546d462c96e16d () mail ! gmail ! com>
X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=126729517323397

On Sat, Feb 27, 2010 at 5:29 PM, Aaron J. Seigo <aseigo@kde.org> wrote:
> On February 27, 2010, Yuen Hoe Lim wrote:
>> Is this a bug or is this intentional? If the latter, then is it acceptable
>> to simply do
>
> looking at your last commit to plasmate, i see why you asked this. all
> plasmoids should have Plasma/Applet in the ServiceTypes= entry of the .desktop
> file, since all Plasma/PopupApplets are also Plasma/Applets. it means we have
> to constantly search for Plasma/PopupApplets to build a complete list of
> applets, and PopupApplet is just a hint for scripting purposes anyways.
>
> right now Plasma::Applet does search for Plasma/PopupApplet as well as
> Plasma/Applet, so this is worked around pretty thoroughly. but i do wonder if
> that code should be made to only rely on Plasma/Applet. the only place
> Plasma/PopupApplet should be needed is in Applet::loadPlasmoid.
>
> the danger is that scripted plasmoids that used to work might stop being shown
> in the applet listings if they just had ServiceTypes=Plasma/PopupApplet.
> however, the documentation on techbase that mentions this as a possibility
> does also state that it must include Plasma/Applet.
>
> so i'm considering removing the references to Plasma/PopupApplet in
> Plasma::Applet except for where it is used to actually create the correct base
> class. Richard: what do you think?
Yes, I think that might be a good idea as there is quite a bit of
special casing. We should be adding support for Plasma/Containment
scripting plasmoids in all the queries too, and if all Containments
were always Plasma/Applets too we wouldn't need to do that. There is
also special casing in plasmapkg for Popups and Containments to work
round the problem with them not being Plasm/Applet service types. I
haven't added special casing for Containments in all the places were
applets are listed yet. I wasn't quite sure if they were something the
end user should see, or whether they were going to be some kind of
'internal' system programming feature.

I don't think all the special casing is a great problem if the
Plasma::Applet scripting family is going to stay as it is for the
forseeable future with just Popups and Containments. But if we were to
start having more of them I think it would be right to always make
sure they are Plasm/Applet service types. As it stands I don't mind
much one way or another - it is a bit messy, but not that messy.

While I think about it the project type selector in Plasmate is
different from how the KDevelop or KAppTemplate ones work. In those
you decide what language you want to use, and then under each language
you have a heirarchy of projects types. With Plasmate, you have a
selection of project types, and they under those you have options for
the various languages. Until recently that hasn't made much
difference, but I think the more types of scripting applets we have
the more confusing it will be not to have programming language at the
top of the selection heirarchy.

-- Richard
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel