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

[Milian Wolff]

Niko Sams, 07.06.2010:
> 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)

As I wrote you separatly, yes - please go ahead. But keep PHP where it's now 
so we can still easily create tarballs for a next release.

> > 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.

Interesting idea.

> > 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?

At least based on the QualifiedIdentifier we could make that work even now. See 
also my other mail in that regard.

> > 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).

still, full flegded external scripts would be nice as well.

> > 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)

All that is already working. You guys don't seem to use my snippets plugin :P 
:P

exporting via GHNS is disabled since the old KDE 4.4 implementation simply 
sucked. The 4.5 implementation is supposed to be better, I just have to 
comment out some code in the plugin to make it work.

Snippets can be associated with Kate highlight modes, which is even more fine-
grained than mimetypes and much more useful, esp. in the Webdev context.

Since 4.5 you can script snippets and I made that work for KDevelop yesterday.

> - 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.

I also thought about the "file-template"-flag and imo it shouldn't be much work. 
Instead of inserting it and showing it during code completion, it would simply 
create a new file.

> > 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?)

Sadly I don't see any.

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

At the moment it would be OK for me, up until the point where we actually have 
real "Quanta-Only" developers (if that ever happens).

For now, lets keep devel discussion on this list and user discussion on 
quanta's list, like Andras proposed.

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100608/d539af64/attachment.sig>