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

[Milian Wolff]

On Saturday 19 June 2010 21:17:35 Andras Mantia wrote:
> 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.

Yeah I don't really care how it's done. I might actually use a toolview for 
starters.

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

Random meaning _really_ random (e.g. lorem ipsum) or random meaning $anything-
the-user-wants? Still, should be solvable with snippets. Both btw, now that it 
can be scripted.

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

OK then we are nearly there now.

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

Ah cool, then I'll finally meet you :)

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

Putting it up on kde-files would be also ok imo. Of course users should _have_ 
to review the scripts they download to make sure they don't run `rm -Rf ~` or 
similar ;-)

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

Well, the XML plugin parses and tries to "understand" real DTDs now, and 
apparently it's working quite well.

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

All cool features that I'll implement in the XML lang plugin now.

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

Yes I completely agree with you here, and I'll try to achieve similar things 
with the XML lang plugin. I still don't see the need for keeping the DTEPs 
around though ;-) But lets discuss that at akademy!

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

Preview meaning the live website (e.g. with the above talked about plugin), or 
just something like "border: 1px solid #000" showing a square with a 1px 
border?

Imo the latter would be nice-to-have and _really_ easy to implement in 
KDevelop. One would just introduce a DeclarationNavigationWidget for CSS that 
has some logic on what kind of HTML to use for what attribute and then simply 
apply the CSS to it.

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