It’s been a long time since the last update, and admittedly I haven’t been working on PlasMate as much as I’d like to in the past month (with school kicking in and all). Anyway, just a quick post to highlight some of the stuff we’ve been up to.
The screenshot at the top shows the beginnings of PlasMate’s project management dialog. Right now it does nothing but lets you load a project. The idea behind this though is that we want to keep project management inside of PlasMate, so that you’ll never need to find or create a location to store or “save” your projects to. PlasMate would spare you that management overhead by taking care of storage somewhere out of sight, and allowing you to view, search, load, and delete your projects from within the project management dialog. As shown in the screenshot, you would still be able to view and load your 5 most recent projects from the start page itself. And you could still export your project, but that will mainly be for creating an installable package that you can distribute or publish.
Expect to see a filter/search bar and a delete button added to the dialog soon. Another feature we have in the pipeline (thanks to Shantanu who brought it up) is an “export all” and “import all” feature which would allow the user to take his projects with him to a new computer or to back them up during reformats or system upgrades. It may make sense to eventually generalize this to being a multi-project export/import feature, we’ll see.
To make it less difficult to import individual projects, particularly from GHNS or directly from a desktop plasmoid where the user has absolutely no control over the target project’s name, we have opted tentatively to support multiple projects with the same name. To help the user distinguish these projects, we plan to eventually list ‘author name’ and ‘version’ in addition to ‘project name’ on the start page and in the project management dialog. The rationale being that imported projects are not likely to be by the same author, and that if the same author somehow wishes to develop multiple duplicate-named projects, he could sensibly use a version string/number to distinguish them. If an unlikely accident creates a pair of same-name, same-author, same-version projects, the user can easily remedy this by loading either one project, checking it’s contents, then immediately changing either of the three distinguishing fields in the metadata editor.
Another enhancement that I recently added is a find-text bar at the bottom of the documentation widget, implemented because I discovered that find-text has become subconsciously quite indispensable when browsing text-heavy documentations. It works pretty much as one would expect.
And finally, Diego has finished some fixes and refactoring on the timeline dockwidget and the workflow menu dockwidget. The timeline’s color problems have been dealt with, and the workflow menu has inherited the timeline’s makeover, allowing it to be docked both vertically and horizontally, as shown in the screenshot above.
That concludes things for this update. It’s a cool feeling because it feels like we’ve come a long way since we were newbies staring at a completely skeletal PlasMate, and yet there’s still so much left to do – GHNS integration, runner/theme/dataengine support, Qt Designer integration, etc etc. Anyway, until next time!
Loading ...
pier
Cool!!! I especially like the find-text idea! it would be cooler if it stays by default hidden and appears when you start typing, so that the docs have the greater space possible :-)
Thanks for your work!
cheers
The User
This is not very cool, I simply do not understand, why you do not use KDevplatform. It provides everything for project-management etc. and the C++-language-support would be definitely useful in Plasmate, too. KDevplatform also provides QtDesigner stuff,
Why should a Plasma IDE not use a highly reusable and straight forward KDE API providing all the needed stuff. You are implementing broing things like project management instead of focusing on Plasma-related features.
The User
jordi
The obvious question is:
What if I am working with svn or git in my project?
I would like to make the project management (i.e. where are my files) obvious then, no?
The User
@jordi
Yet another reason to use KDevplatform…
Jason "moofang"
@ pier : Yeah, would probably do that (default-hide the find-text bar) :)
@ The User : I apologize if you don’t find it cool, but at least on my part I think it’s pretty interesting because PlasMate is handling code projects in a way that I haven’t seen any other development tool do before, though I won’t claim that I’ve seen many. In a single app we are storing, transparently version-controlling, managing, packaging and distributing these projects without ever exposing the structural details of the projects or the mechanical details of their developmental lifetime – we are creating an intuitively simple but complete abstraction. This is precisely what we aim to do by the way – to allow the user to effectively produce awesome applications using a purely high-level understanding of the process and without needing to bother about all the icky details.
Re: KDevPlatform I may not be the right person to ask about this since I’m not too familiar with the KDevplatform libraries. However there is a general consensus in Plasma that PlasMate should be fundamentally different from KDevelop. We don’t want to create an IDE, with all that power and options and complexity. PlasMate is a tool that you use to craft small apps with the least amount of hassle. As is commonly said – PlasMate is more KWord than KDevelop. The use-cases, target audiences, and overall philosophy of the two are really quite different.
Third-party extension developers should also absolutely not be using C++, and thus we have no plans to include C++ support into PlasMate.
And finally, I’d like to clarify that we aren’t taking redundant time here recoding project-support from scratch – Plasma takes care of recognizing/estabilishing the project structures of the various components. What we’re doing here is merely developing the front-end GUI and designing the user-interactions. I’m pretty sure we’d need to do all these anyway if we used KDevPlatform.
@ jordi : We don’t think it makes too much sense if you could do everything in PlasMate EXCEPT version control, and we don’t want to create GUI frontends to svn inside PlasMate to increase the management complexity (I don’t like using those GUI’s too, eeww). So PlasMate has it’s own versioning system built in, in the form of an easy-to-use “timeline” on which you can estabilish “save points” and freely revert between them. The main disadvantage of this compared to using standard svn/git is you cannot easily collaborate between developers since the version control is local, but we think this won’t be a problem for the majority of extension developers, since extensions are small projects and their developers don’t usually collaborate for long terms (if they collaborate at all).
We are looking at the possibility though – since the backbone of the timeline mechanism is Git, I believe Diego is looking into the possibility of pushing projects onto Gitorious. We’ll see how that turns out :)
The User
Why shouldn’t I want to use C++? Or why shouldn’t C++ developers have some nice Plasma-specific features?
However, I think KDevplatform provides more elaborated ways to add support for a language like Python and xml-support could also be useful for Plasmoid-devs. And Plasmate would definitely benefit from the plugin-system, version control, or why does not it use KAppTemplate?
KDevplatform is a very abstract library. There is the interface IProjectController, so that you can import normal kdevelop-projects, CMakeLists.txt, automake-files or whatever. Then KDevplatform provides some modular stuff like version-control, language-support… You can use standard-uis or use such interfaces to build your own ui. Why should Plasmate implement its own plugin-system? Or why shouldn’t Plasmate and KDevplatform work together on better documentation? Maybe there is not too much redumdant stuff, but when Plasmate wants to become more elaborated, there will be.
Jason "moofang"
Badly written C++ plasmoids can crash Plasma, but we can sandbox scripted plasmoids, so we want to discourage C++/binary third party applets. C++ plasmoids are also a little ickier to manage (compile, cmake and stuff), and we feel scripted languages are an overall more sensible platform in the context of plasmoid/runner etc development.
WindPower
Oh, please! I’m doing to use this! (On le new shiny KDE4.4!)
WindPower
Uh, I meant “dying”, not “doing”. (Oops.)
Jason "moofang"
If all goes well we should have an alpha release around the time of KDE (SC!) 4.4’s release :) Hope it’ll be up to your expectations ^^; It’s somewhat far from polished though at this stage.