KDE Releases Plasmate 1.0, A Plasma Workspaces SDK 16
jrepin writes "The KDE Plasma Workspaces team is excited to announce the first stable release of Plasmate: an add-ons SDK that focuses on ease of use. Plasmate follows the UNIX philosophy of "do one thing, and do it well". As such, it is not a general purpose IDE but rather a tool specifically tailored to creating Plasma Workspace add-ons using non-compiled languages such as QML and Javascript. It guides each step in the process, simplifying and speeding up project creation, development, adding new assets, testing and publishing. The goal of Plasmate is to enable creating something new in seconds and publishing it immediately."
they are misusing the term "UNIX philosophy" (Score:5, Insightful)
This specific bit of the "UNIX philosophy" is referring to the transformation of STDIO to facilitate piping. That is clearly not what this tool is designed to do: Plasmate clearly encompasses every part of a specific task, instead of being a general tool designed for reuse in any context to achieve any task.
Re:they are misusing the term "UNIX philosophy" (Score:4, Insightful)
a general tool designed for reuse in any context to achieve any task.
[awk] is not designed for reuse in [my dishawasher] to achieve [cure for cancer].
Therefore awk does not follow the UNIX philosophy. Lather, rinse, repeat for any and all UNIX utilities, functions, etc.
Oh any "everything is a file" is a lie too. I can't open a TCP connection by opening a file, I have to use sockets, which are a different paradigm. Don't even get me started on shared memory!
Re: (Score:2)
The goal (Score:2)
The goal of Plasmate is to enable creating something new in seconds and publishing it immediately.
May I chose a tool that helps create something of good quality? I'm quite sick of crap published in seconds only because it's new.
"do one thing, and do it well" (Score:2)
Is "do one thing, and do it well" really still the Unix philosophy - for GUI stuff as well? This works great for command-line stuff, where you incorporate commands into pipes and scripts. But user expectations for GUI apps are more like "anticipate my needs and surprise me by being able to do obscure function x that I didn't even know I needed until now". Some would call that bloat, but whatever. My point is that GUI stuff is different than command line stuff, if only because you don't paste multiple GU
Re: (Score:3)
I call it utter crap to describe a useful GUI as bloat.
A useful GUI will be a graphical front end (really!) to the actual tools a nerd or specialist would employ via command prompts. The non-specialist does have little knowledge of the proper names or spelling of tools he otherwise knows to exist, the GUI is the reminder, the pick list if you like, and a good GUI will lead him to a workable solution.
The useful GUI will also supply sufficient information for the non-s
Re: (Score:3)
I agree that a gui doesn't fit the description but a gui can be made up of components that do.
Re: (Score:2)
So you mean COM/ActiveX?
Re: (Score:3)
My point is that GUI stuff is different than command line stuff, if only because you don't paste multiple GUI apps together to accomplish more complex stuff.
Clearly he's never seen a tangible functional interface [youtube.com] with direct manipulation before.
Re: (Score:2)
Not really. There are many GUI applications that delegate the actual performance of the functions to other parts of the code. Sometimes libraries, and sometimes separate application. No *real* difference here, except for packaging.
OTOH, that's a "slippery slope", as libraries tend to be integrated into code in ways that separate applications can't be. But still, it's basically the same thing.
That said, I will admit that MOST GUI applications are of the more tightly integrated variety. There are good pe
Re: (Score:2)
The performance reasons are often overplayed anyway. Unix has cheap process creation and anything you call frequently will be cached.
Re: (Score:3)
Is "do one thing, and do it well" really still the Unix philosophy - for GUI stuff as well?
Well, it can be.
This works great for command-line stuff, where you incorporate commands into pipes and scripts.
There are many programs which consist of one or more command-line tools which perform the heavy lifting, and a GUI which calls them. That is an example of GUI programs which follow the Unix way. If this program works that way, then it follows the Unix way. If not, then not, because it could.