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

[Andras Mantia]

Late answer to this mail...

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

The good side of the toolview is that you can see the same time the 
rendered and not rendered version.  Splitting might work as well, and 
sincerely I cannot judge which one would be better for the users. 

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

The DTEPs are used to parse the document. After parsing a DOM-like tree 
is created. That is independent of the DTEP, that is a result of some 
parsing (as I understand DUChain is something like this tree). And the 
structure tree visualizes this tree. 
 
> 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... 

I still think there is some confusion regarding the DTEPs. :) But it is 
not that important atm. Anyway, I see no problem if we provide a 
different toolview to navigate through XML and another toolview that 
shows the PHP/JavaScript/CSS/Ruby/whatever stuff.

> > b) insert random tags
> 
> What do you mean by random tags? User-configured tags?

Typo, read "insert random text".
 
> > > 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.

Ok, that's fine.

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

No, I just meant that we need to make configurable actions, not KActions 
created upfront in the code. Regarding input (for the external script), 
that can be from the document (selection, whole document, document's 
path, project path). If the scripts needs user interaction, it is its 
job to provide an UI. That was in most cases via Kommander in Quanta3, 
but it can be anything, like a PyKDE app.

> Ah ok. But my experience with XMLGUI is: It's a horror. 

No promises, but maybe at Akademy I will find time to do it again for 
KDE4. :) So if you can get until the place where we can group the 
actions into logical groups (well, probably a KActionCollection), I can 
try to do again putting them on a toolbar.

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

Yeah, we have something on our server, don't know if that still works 
with KDE4's GHNS. What is important in that case, that there is a need 
to verify that downloaded scripts are from valid source. The idea was 
that they need to be signed, so the one who downloads can decide if he 
trust the signee or not. I extended GHNS at that time to support 
signatures, but I have no idea if this feature is still in KDE4 or not.

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

Yes, there were dialogs, and sometimes they are useful (think that even 
C++ language has dialogs/wizards). But autocompletion should be enough 
in most times, I agree.  For good completion, you need good parsing and 
understanding of the document. That's where the DTEPs came into, so 
Quanta could know what attributes are allowed for a tag, or inside a tag 
what other attributes were allowed, so when you typed "<" it could offer 
the valid tags.
 BTW, in case you didn't know, Quanta could do the following:
- typing a tag would fill up automatically all the required children 
tags. Eg. <ol> must have at least one <li></li>. So when the user 
finished to type <ol>, Quanta inserted 
<ol><li></li></ol>.
- typing a tag inserted its closing tag. Eg <a> insterted <a></a>.
- if a tag was unclosed, typing </ would insert automatically the right 
closing tag.

Of course all these were configurable, but turned on by default. And I 
think it helps a lot with writing XML.  This is somewhat different from 
C++, there the most closest feature is the automatic insertion of 
closing paranthesis or quotation mark.

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

Yes, the good idea (although not completely working) in the editor was 
that you had a preview of the CSS. 

Andras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100619/d16c44d3/attachment.sig>