importing XML, CSS, Upload, Xdebug, Execute Script, Execute Browser etc. pp. plugins into Quanta

[Niko Sams]

Hello!

> I'd like to incorporate most of the webdev related plugins in playground into
> Quanta and continue improving them there.
I'm all for it.
But what about php plugins? We might want to release 1.0.1 together
with kdevelop
(as there won't be a stable quanta)
Maybe we should move it too and create the tarball out of the quanta repo.

I can do the git conversion if that helps you (I have the svn repo locally)

> I've talked with Andris and I'll probably remove most of the existing code in
> Quanta and replace it by implementations that reuse the existing frameworks
> better. I still hope to be able to reuse some old code, but most of the
> existing code seems to reproduce exiting code in KDevplatform, often in a
> quite different way though, making the porting non-trivial.
That is really unfortunate. But maintaining alternative implementations of stuff
that is already in kdevplatform doesn't make sense.

> [...]
>
> Looking at the existing plugins in Quanta that are halfway working I can say:
>
> KDevHTMLPreview - sounds useful but is probably superseeded by executebrowser,
> or Niko? Do users really need/want a inline HTML preview? Anyhow, the plugin
> needs to be ported properly (its not doing anything right now).
With an inline HTML much more can be achieved, like offering code
completion in css
for the current html site, or highlighting selectors...
It could be implemented in the executebrowser plugin.

> KDevStructureTree - nice idea and people might be used to it. It heavily
> depends on the DTEP stuff though and I want to get rid of that. I'd rather try
> to implement a "context-outline" or similar thats shown in a toolview. That
> way it would also work for Cpp etc.
Or the outline quickopen could show tree structures?
And the outline could be in a toolview?

> KDevUserToolbars - Some UI is working, but it's messy and the actual actions
> don't seem to work at all.
I did never use the predefined toolbars, however I created custom ones
that where
basically scripted snippets.

> Anyhow, I do see the need to run a script quickly
> or insert a tag.
No - it's not about running the code the user writes - it's about
something like scripted
snippets (or text-processors).

> But: To me it would make more sense to associate actions with
> Snippets, Launch Configurations (e.g. Execute Script, Execute Browser, ...)
> then to have this toolbar plugin reinventing the wheel. Still, creating new
> toolbars would still be needed for those that really want an icon for the
> actions. Hence that part of the plugin should stay, but the rest should try to
> reuse the KActionCollection(s) and simply offer the user to add actions from
> the usual "configure toolbars" page... Maybe we should even request such a
> "add toolbar" feature inside KDELibs directly.
Ok, my vision:
- implemented in snippets plugin (for kdevelop too)
- share snippets with GHNS / export & import
- default snippets shipped with quanta depending on the mime-type
- scripted snippets as KTE scripts (JavaScript)
- possibility to assign shortcuts to snippets (not important)
- possibility to add snippets to the toolbar (not important)
- scripted snippets that call external process (not important)


> KDevTemplatesTree - Again, needs to be ported to work properly and it should
> be merged with Snippets probably. We have project templates but - beside the
> "add class" wizard - no way create a new file from a snippet. This seems to be
> very useful to me and I'm willing to make that work properly.
I never used that. I used regular snippets for new files.
If it is implemented as snippet with a "file-template"-flag it can be
useful. I wouldn't
spend too much effort into it.

> KDevQuantaCore - Imo, this should die. We have TextDocuments,
> CodeRepresentation etc. pp. inside KDevplatform that would supersede the
> EditorSource. The rest is DTEP related or even "background parser" like and
> should all be removed. Instead plugins (e.g. the XML one) should contain the
> required actions and - if required for e.g. the "insert tag" actions - install
> an interface _just for that_.
+1

> Of course, users will complain again about missing features etc. pp. but well,
> porting all of Quanta3 massive feature set is simply a too huge task for this
> short time and a single person.
Quanta4 is a new application, as KDevelop4 is. So I think dropping
broken features
is Ok. (well, is there another choice?)

Oh, and Quanta does have it's own mailing list, but maybe we should stop using
it as quanta is just a kdevelop project.

Niko