Adding Bitbar functionality to Plasma

[Lasath Fernando]

Heh, Thanks!

I'm not sure how much we want to treat it as a super first class citizen,
> given output will never look as native or be as dynamic.
> I don't think we want any of our main applets written in it, but
> supporting it like we support the web slice as a plasmoid, seems pretty
> sensible.
>

Depends on what you define as "first class citizen". I really think it
should have the same quality and visual polish as the main applets.
However, I agree it doesn't make sense to write any main applets in this
protocol: it's a different use case.
This is for applets that explicitly don't want to control/own their UI;
they just have a rough list of content and want Plasma to take care of
making it look pretty.

Some examples I use it for:

   - List of pull requests on Azure DevOps.
   - List of assigned bugs from Azure Boards.
   - Weather forecast excerpt showing if conditions are good enough for
   flying with a private pilot license.

I think the original author of Kargos used it to display an RSS feed.

Currently it's an applet right? It seems like a sensible design as it
> shields the shell from caring about the applet internals which I like.
> What are the specific problems with this that we want to address?


Right, applet it is. In that case, what's the current guidance on doing
business logic in QtQuick (Js) vs C++?
Should I create a native plugin for it? IIRC the instructions for that were
a bit cryptic, so I might bug you on IRC when I get stuck.
What times are best for you? 9-5 BST?

If the guidance is to do as logic in QtQuick as possible, I'll still need
help with reading the files.
AFAICT the only way to interact with the filesystem from QML was the
"filebrowser" data engine, which I could not get to work.

In the meantime, I want to confirm that these are still the
correct/up-to-date instructions to follow regarding setting up a dev
environment:
https://community.kde.org/Get_Involved/development#Plasma_Desktop
It suggested using kdesrc-build for handling dependencies. I run Arch Linux
which has the latest released version of everything. That means I don't
need to bother with it, right?

Cheers,
Lasath

On Mon, Sep 21, 2020 at 8:28 AM David Edmundson <david at davidedmundson.co.uk>
wrote:

>
>
> On Mon, Sep 21, 2020 at 7:44 AM Lasath Fernando <kde at lasath.org> wrote:
>
>> Hello There!
>>
>> I don't know if any of you remember me -
>>
>
> Of course!
>
> it's been many years since I made any contributions to KDE. However, I
>> would like to change that! :D
>> Recently, I became the maintainer for a plasma applet called "Kargos":
>> https://github.com/lipido/kargos
>> It's a Plasma port of Mac OSX's BitBar: https://github.com/matryer/bitbar
>> (I tried to include a screenshot, but it looks like these mailing lists
>> have a limit of 40KB)
>>
>> Those github pages give a lot of detail about exactly what it does and
>> how to use it, but the short version is that it runs a given script
>> periodically and displays the stdout in a panel.
>> This has made Plasma applets much more accessible to anyone that knows
>> programming (or even shell scripting), as they can simply instantiate this
>> to watch something. (No need to worry about Ui/Layout logic or Qt/QML at
>> all).
>>
>> However, I believe this kind of functionality should be built into Plasma
>> itself, rather than being a far-away applet users have to stumble upon.
>> (Kind of like how the earlier versions of Chrome included direct support
>> for Firefox's Greasemonkey scripts without users having to install the
>> Greasemonkey plugin ;-)
>>
>> First of all, I would like the Plasma team's blessing before I start
>> doing any significant amount of work on this.
>>
>
> It existing somewhere as a thing. Sure.
>
> I'm not sure how much we want to treat it as a super first class citizen,
> given output will never look as native or be as dynamic.
> I don't think we want any of our main applets written in it, but
> supporting it like we support the web slice as a plasmoid, seems pretty
> sensible.
>
>
>> Secondly, (assuming I have the first), I would like to hear your thoughts
>> on the best architecture for it.
>>
>
> Currently it's an applet right? It seems like a sensible design as it
> shields the shell from caring about the applet internals which I like.
>
> What are the specific problems with this that we want to address?
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20200921/c2605fe3/attachment.htm>