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

[Milian Wolff]

Andras Mantia, 08.06.2010:
> (Resending to you as it didn't appear on kdevelop-devel yet).

Strangeness, Amilcar - do you know anything about that

> Hi Milian,
> 
> On Monday 07 June 2010, Milian Wolff wrote:
> > Andras: Are you OK with me moving most of the Quanta code to the
> > 'UNPORTED' folder?
> 
> Instead of removing stuff, I like the idea of moving it somewhere (or
> create a git clone where the current code is accessible) better. There
> might be code there that can be reused, and would not make sense to port
> again from KDE3 what once was done. If everything works in the end, we
> can get rid/forget this copy.

Yes, I'll go on using the UNPORTED folder for stuff that I think we might want 
to port in the future.

> > Looking at the existing plugins in Quanta that are halfway working I
> 
> > can say:
> See my comments there. Note, I was never a real web designer, I used
> Quanta only for a few projects, but I had quite some feedback from the
> users from the time I developed it, so I have to think I went into the
> right direction with some of the design. ;)

I definitely didn't want to imply the code itself is dirty or bad designed. 
It's just very similar to the Quanta3 stuff and doesn't reused KDevplatform 
where it could do so. And duplication leads to problems sooner rather than 
later imo.

> > 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).
> 
> I'd say, yes, this is important and one of the easiest to port. In
> Quanta3 it supported only KHTML, but it shouldn't be a hard job to
> support the kwebkitpart as well. It is very handy to preview a page
> inside the app. Otherwise you need to launch a browser (even from inside
> Quanta) and later when you test changes switch to it and refresh the
> page there. Integrated preview can be useful in the use case when you
> view the preview in a toolview, e.g in the bottom and you develop and
> you see an instant (or almost instant) update of the page you develop.

Ok, I'll port it. Since KDevelop can embed any KPart it should be rather easy. 
Inside a Toolview we could even use a QWebView but imo a toolview is not the 
best place for something like that. Rather we should use a tab (the user might 
split the view if desired) and update on demand.

> > 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.
> 
> I don't understand what context-outline is.

Inside the DUChain you have lots of contexts, e.g. in PHP for every function, 
class, file, namespace you'll get your own context.

I thought / hoped to reuse something like that for XML tags and display the 
outline that way.

> The structure tree was one
> of the central parts of Quanta3. It is like a class view for a C++
> project, gives you an overview of the document. It can be used for quick
> navigation, can be used to see if your document's strucutre is very bad,
> and even used to find the problematic places. The few times I wrote
> html/xml with Quanta, I used a lot.

OK, good to know.

> It also integrated PHP classes, but
> that should now be the part of the php language support.
> This is not DTEP related, it is tied to the internal document tree. A
> visualization of the DOM tree, we can say. DTEPs are just the rules of
> parsing, so you know that tag <foo> can have N attributes and M children
> (and the name of the children), etc. Just like DTDs, but in Quanta
> specific language.

So you need the DTEPs to create the document tree to show inside the tool 
view?

Since it seems to work even now, I'll investigate what would be required to 
keep the DTEPs just for that feature. Of maybe we can reuse them more inside 
the XML plugin.

Anyhow, if we'd stick with the DTEPs we'd get a ToolView that's only useful 
for XML and similar markup files... Maybe we can somehow make the "outline 
toolview" pluggable so that languages can overwrite the behavior. That might 
actually be quite useful as soon as the language has important syntax elements 
that are not mapped to the DUChain.

> > KDevUserToolbars - Some UI is working, but it's messy and the actual
> > actions don't seem to work at all. Anyhow, I do see the need to run
> > a script quickly or insert a tag. 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.
> 
> Again, this was one of the "selling" points and one of the most powerful
> parts of Quanta. The main idea is not behind the toolbars, but behind
> the actions. You could create custom actions to
> a) insert tags
> b) insert random tags

What do you mean by random tags? User-configured tags?

> c) execute external applications (and together with DCOP at that time,
> that can be DBUS/Kross, whatever this days, the external apps could read
> the editor content and modify it).
> 
> These could be organized in groups and the visualization of the groups
> were the toolbars. Why is it good? For example, you don't have to hard-
> code actions for inserting tags. Like CTRL-B to insert <b></b>. And when
> <b> got deprecated, changing to <strong> requires no change in C++ code.
> You could execute scripts like HTML Tidy, or external wizards to create
> a new document or part of a document. Even preview with external
> browsers was done through them, making it easy to add support for a new
> browser also for the users.
> 
> E.g I have scripts to insert snippets, to update the permission on the
> project files and to run a fancy svn updater or a remote server through
> ssh. ;)

The scripts we have in Kate and KDevelop nowadays are (beginning  with KDE 
4.5) scriptable in QtScript. you can access the whole Kate Scripting API in 
them.

What you cannot do is run external tools, which would really be a useful 
feature.

I completely agree with you that this is an awesome feature and that I should 
try to port it. But: I want to adapt the implementation to what we have. We 
have Snippets. We have Script Execution. What we need is:

snippets:
- more default snippets
- actions for snippets
execute script:
- ability to pass arguments to scripts (niko, is that already possible?)
- ability to replace editor contents / selection with output of script
- ability to change contents inside the editor from the outside via DBUS
custom toolbars:
- ability to group actions in custom toolbars

> > 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.
> 
> Because of the above, simple KActions are not enough, the user would not
> be able to customize them.

The action is simply there to execute the - well - action. Configuring it would 
be done in the snippet configuration or script launch configuration.

Or do you mean additional input whenever the action gets executed? There is a 
GSOC going on that would give us that ability as far as I can see. If need be 
we can still show a dialog on executing the action and ask for more input 
there.

> As for the visualization part: that part of
> the code is one of the hackish parts, dealing with the XMLGUI internals.
> I don't know how it works atm, I know it wasn't easy to get it working
> in KDE3 and in the first KDE4 port. BTW, Configure Toolbars *could* be
> used to modify the toolbars.  The Quanta specific part is the dialog that
> you use to create custom actions. This somewhat replicated the Configure
> Toolbars functionality, to make it easier to do the job (creation and
> organization) from one place.

Ah ok. But my experience with XMLGUI is: It's a horror. I'll probably deferr 
that to the end of my GSOC and try to make it possible to assign shortcuts to 
the actions at least and do the other stuff regarding snippets and scripts I 
talked about above.

> Actions and toolbars were also sharable, either by just sending them by
> email to somebody or through a get-hot-new-stuff framework. Let's say
> somebody created actions and toolbars (with the most important tags to
> insert) to write KDE documentation or some random XML, they could share
> it with others. Even if the GHNS part is not implemented now (probably
> too much work), having the rest in place will make this possible.

Actually GHNS is pretty easy to setup. It's just a pita (or was, I didn't test 
it recently) to update existing uploaded content.

> > 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_.
> 
> I don't disagree with this. If the new design leads to code that can be
> done without whatever is in QuantaCore, it can die.
> 
> > So, I kinda feel bad but I really have to ask this: May I move more
> > or less _all_ the Quanta files to UNPORTED and start "clean" with
> > the current plugins (xml, css, upload, ...) we have? I hope that
> > this would increase my productivity and make it possible to have
> > something that is actually useful. 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.
> 
>  You know, the one who codes, decides. Especially about coding. ;) But
> now I abuse my power as a mentor, and I'd like to keep the above, namely
> the internal preview, the custom actions and the structure tree. 

You don't abuse it. That's just why I asked you before removing stuff wildly :)

> Of course together with autocompletion.

Actually I still think that we should make this a much more important part as 
it was in Quanta 3 times. There you often had cumbersome dialogs to create a 
tag with all it's attributes. For adding an attribute you'd have to fire up 
that dialog again and again...

Using _sane_ code completion would solve this issue in a much nicer, faster 
and less intrusive way.

>  What people liked was the uploader part, but that is something Niko
> already worked on, I don't know the status.

It's supposed to work, I have still not tested it. I'll import it into Quanta 
soonish and test it to make sure it works as intended.

>  The idea of a CSS editor is also nice, I have no idea in what state it
> is. That wasn't written by me, and actually I know little of the code.
> If CSS autocompletion will work, that is already a good step.

See above: code completion ftw, dialogs ftl. :)

>   The poll idea is great, please do it, and be sure to announce on
> quanta-users.

OK, thanks for the note.

>  Yes, people will complain, but we will try to get the message through
> that this isn't a port, more a rewrite and has to grow. Just like
> KDevelop4 has to. ;)

:) I'm totally with you in that regard.

Bye

-- 
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/fe55acdd/attachment.sig>