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

[Andras Mantia]

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.

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

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

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

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

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

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.

> 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. Of 
course together with autocompletion.
 What people liked was the uploader part, but that is something Niko 
already worked on, I don't know the status. 
 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.
  The poll idea is great, please do it, and be sure to announce on 
quanta-users.
 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. ;)

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/20100607/06b2243f/attachment.sig>