[Kommander-devel] KTextEditor in Kommander

[Eric Laffoon]

On Thursday 17 August 2006 12:14 pm, Andras Mantia wrote:
> On Thursday 17 August 2006 19:42, Eric Laffoon wrote:
> > On Thursday 17 August 2006 3:37 am, Andras Mantia wrote:
> > > On Thursday 17 August 2006 12:33, Andras Mantia wrote:
> > > > Highlighting mode cannot be changed right now. The solutions
> > > > would be: - change from the context menu
> > > > - a dropdown combo in the editor dialog
> >
> > The highlighting is great, except we really only have two absolute
> > blocks. It would be more meaningful if we did...
> > @function() - highlighted - ("content") not highlighted
>
> That is possible.

Looking for svn commit. ;-)
>
> > @functiongroup.function - probably same highlighting as function
>
> This one should already work.

Yes.
>
> > @widget.method - ideally different highlight
>
> This will not work, as highlighting is based on regexp matching and not
> on content. Except is if we list all the possible function names in the
> highlighting file and we assign a different color to them.

That's why I attached the file. You need a PHP CLI executable to run it and 
set the correct path to get the function names. Unfortunately I was mixing 
stable and unstable on my system and seem to have lost CLI so I have to tend 
to that when I have a minute I'm not dog tired... but last I used it it was 
working great.
>
> > This should not be too difficult as these can be neatly extracted.
> > Attached is a file I used to make the dcop aide dialog. As we
> > eventually will support the new script too this may make things a lot
> > easier.
>
> I don't think we could correctly highlight such a file. This is PHP and
> Kommander. 
The PHP is to get Kommander functions from the source as they are easy to 
extract, not to make a nearly impossible highlight file. ;-)

> In Katepart it isn't possible to mix highlighting files, so 
> you say one part is highlighted as Kommander the other as PHP. The
> current Kommander highlighting is based on bash highlighting as bash is
> the most used language with Kommander. But even there if you have a @
> command inside quotation marks, it won't be highlighted. This would be
> possible if we would completely ignore everything else and just
> highlight the Kommander commands. Do you want that?
>
> > > It works now from a context menu. The setting is not saved though,
> > > so once you close the editor, it's gone. There could be implemented
> > > a saving of this configuration in the Kommander XML file.
> >
> > You mean in the*.kmdr file? I believe Michal said we had a good place
> > there for random data.
>
> Yes and no. Things like bookmarks, highlighting information should go to
> the .kmdr file. Settings like find options should go to the
> kommanderrc.

Michal will have to confirm where to put them.
>
> > I have to go eat breakfast and do some things but I'm eager to try
> > this out. It's very exciting. I also wanted some form of revert/undo
> > for after testing a file and I expect undo will not work after
> > closing the editor, but it's still very nice to have it.
>
> Undo/redo works inside the editor unless you close the dialog or switch
> to another widget's dialog. This has very good reasoning: the editor is
> different object in each case, so undo/redo information cannot be
> stored. Sincerely I don't know how this could be solved in a good way.
> There could be a global undo/redo stack which snapshots the whole .kmdr
> file content for example when an associated text is edited, so it would
> be possible to undo all the changes made to a widget's text in one go.
> But this is up to the whole Kommander application to implement it and
> choose the points where undo information is saved.

That's sort of my idea. In order to test a dialog you must close the editor to 
run it. The editor is modal. Run automatically saves instead of using a temp 
file so users never have to hassle with saving... However if you really break 
things it would be nice to have a way to revert. My previous suggestion is 
that *.kmdr files are small so it would be relatively little problem to have 
a configured number of 3-10 or so save snapshots in a tmp directory. This 
would allow you to revert to pre-test or before. I also think Kommander 
should have a default and it might be good to optionally configure this per 
dialog. If I have a highly critical one I want more saved and if I have a 
less critical but really large one I want less. Normally I want the default 
few.

It appears we have very similar ideas but I'm open to whatever is easiest to 
implement.
-- 
Eric Laffoon
Project Lead - kdewebdev module