faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
KFileReplace only in Quanta?
by Zoltan Bartko on Thursday 06/May/2004, @22:50
|
Folks, I can only admire what you are doing, but let me ask you something: Is KFileReplace a thing that could be integrated into Kate too? I am not trolling, it is not a problem for me to do the things I want in Quanta and then return to Kate (converting the code of a Slovak document management system written in plpgsql (see also: PostgreSQL) into English), but you know, what effects lazyness has on mankind... Thanks for reading this far.
Zoltan |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: KFileReplace only in Quanta?
by Anders on Friday 07/May/2004, @00:02
|
AFAIK KFileReplace is a standalone app, so you can just use that. Missing would be the ability to open files in kate automatically (a guess, I use perl to change things in files on disk ;).
Using it as an external tool, you'd be warned if anyting had changed in open files inside kate, with the option to reload those.
If KFileReplace is implemented as a KPart, it would be fairly simple to write a kate plugin, which could then be shared by quanta if i understand things correctly.
In my opinion, the ability to replace over multiple files in kate is more important than integration with this tool, but if you write a plugin it will be wellcome in kdeaddons, and I'll as allways be willing to help on the #kate irc channel at the freenode irc network.
|
[
Reply To This | View ]
|
Re: KFileReplace only in Quanta?
by Andras Mantia on Friday 07/May/2004, @00:16
|
KFileReplace is already a KPart and can be used also from Konqueror. ;-)
|
[
Reply To This | View ]
|
Re: KFileReplace only in Quanta?
by Eric Laffoon on Friday 07/May/2004, @00:50
|
The original KFileReplace was written as a stand alone application and was maintained through KDE 3. Our version has been updated to a KPart, which is how we use it as a plugin in Quanta. Quanta can easily embed KParts as plugins by using the plugin editor on the settings menu. This version of Quanta also uses Kate plugins. (Settings>Configure Editor::Plugins) So if you can write a plugin for Kate that's great... but it seems to me you can access everything now from within Quanta 3.3 BE 2.
Along with this take a look at Settings>Configure Actions and note that you can interact with the editor content using any scripting language. Actions can be triggered from a toolbar, key combination or template insertion. They can take input from the entire content, selected text or none and outputs to editor content, selected text or cursor. You can also build dialogs with Kommander. Now Kommander is capable of saving the value of any widget as well as having it's widgets manipulated by DCOP. Open kdcop and look at Quanta and a Kommander dialog (kmdr-executor-[pid]). Kommander can get the caling dcopid as well as it's own and you can write DCOP scripting within the dialog and even initialize widgets with population text. You can lift elements out of the editor, create lists, whatever you can imagine. Kommander and Quanta give you a virtually extensible environment where you can write your next upgrade in bash, perl, python, ruby or even PHP if you have 4.3 CLI installed. If you like you can even use all of them. ;-)
We're planning a new release in a month that has data access, a simplified interface, a small collection of special funtions with a function wizard, DCOP simplification mapping and tutorials and demos. Kommander enables users to convert a number of universal applications into a single personal application. Our objective is to make it newbie friendly yet extremely productive by focusing on conceptual flow instead of the constraints of language. People inherently have difficulty putting concepts into lannguage so it's about time someone advanced a conceptual paradigm.
You can get on our new Kommander list to ask questions and get help at http://mail.kdewebdev.org/mailman/listinfo
|
[
Reply To This | View ]
|
Re: KFileReplace only in Quanta?
by Anders on Friday 07/May/2004, @01:18
|
Anyone who wants to write a plugin for kate using kfilereplace is wellcome.
Same goes for kommander.
I'm not really seeing myself installing quanta right now, since i have more than enough to do and I wont use it for anything but a shiny thing to look at.
Personally, I still believe that we should merge kate, kdevelop, quanta and kile into one very simple (KMDI) shell with a unified plugin interface and a profile system, allowing you to define a custom application. I really find this hunting good features/implementations from the sibling applications silly.
|
[
Reply To This | View ]
|
Re: KFileReplace only in Quanta?
by Eric Laffoon on Friday 07/May/2004, @17:53
|
> Anyone who wants to write a plugin for kate using kfilereplace is wellcome.
Sure. We didn't do anything really special we just made the part and incorporated some DCOP so it's pretty standard.
> Same goes for kommander.
Kommander doesn't currently create KParts, though that could change. It uses the Qt Designer base to make a KDE application. The editor builds dialogs, which are essentially *.ui files renamed to *.kmdr and containing KDE widgets that inherit Kommander's ability to bind text to widgets. The executor runs the dialogs. There is also a side project to make stand along dialog applications.
> I'm not really seeing myself installing quanta right now, since i have more than enough to do and I wont use it for anything but a shiny thing to look at.
Whatever. We actually had someone working on a Document Type Editing Package for Povray.
> Personally, I still believe that we should merge kate, kdevelop, quanta and kile into one very simple (KMDI) shell with a unified plugin interface and a profile system, allowing you to define a custom application. I really find this hunting good features/implementations from the sibling applications silly.
Up till now I had the impression you had some technical savvy but that is now difficult to sustain. Kate is integrated into Quanta effectively and the editor part is used by Kdevelop too. I'm not sure about Kile but I think so. I think that was an application I emailed the developer and offered to work together and got no response, but they seem to have done a good job with it. We looked into trying to merge the Kdevelop framework because I really like it. We're working on being able to share plugins. We're doing what we can there but there is one limiting factor... It's a helluva lotta work!
While I try to go to great lengths to make users happy there are some times where I have to tell the user that it's a lot easier for them to download and build these applications that it is for us to put in thousands of man hours. Not only that you said "simple" and I find this so incredibly bizzare I should probably just avoid answering it. No matter how brilliant you are there is a limitation in how much you can defeat the inverse relationships of focus to diversity and features to simplicity. Then there is the matter of who decides what and the inevitable loss of both focus on and competitive ideas that exemplifies the Microsoft monoculture.
Frankly going too far in merging things together makes it hard not to end up with a steaming pile of crap that everybody walks away from. Having said that I will conversely say this about my little part of the world. Quanta can directly load Kparts from the user interface without writing anything. Quanta will probably be able to load Kdevelop plugins soon and it already does load Kate plugins. Quanta *is* KMDI in this release and Andras is now one of the maintainers. All of this seems of nominal use if you're not going to bother to load it.
Given the disturbing rate of the escalation of complexity in Quanta we are looking at a system to enable "personalities" to be enabled for projects and users. This will allow task driven interface customization. Given the nature of our user model I don't think it's rational to attempt to constrain it to other applications user models. Also Quanta is the kdewebdev module now with 5 additional appliations a 6th pending and a 7th in review. Quanta is already merging with applications and already has a high degree of reuse. We already are striving for interperability. We are NOT going to abandon our focus on web developers by throwing Quanta in a pile and stopping all work on everything but making it work again for six months though.
|
[
Reply To This | View ]
|
Re: KFileReplace only in Quanta?
by Andras Mantia on Saturday 08/May/2004, @02:19
|
> Personally, I still believe that we should merge kate, kdevelop, quanta and
> kile into one very simple (KMDI) shell with a unified plugin interface and a > profile system, allowing you to define a custom application. I really find
> this hunting good features/implementations from the sibling applications
> silly.
The idea is good (in theory), but unfortunately it's hard to do (IMO). I can mostly talk about Quanta's POV. It's true that we modularized a lot in the recent time, but still it is quite monolithic and I don't see it easy to break down in pieces. We can do it step by step, and supporting each other's plugins is a good start. Or better: having a common plugin system is the good start.
Currently Quanta's plugin system is fairly simple It can uses *any* KPart as plugin. The configuration (like what URL should be opened when the KPart is loaded) is saved in a simple .rc file. I believe in Kate (in KDevelop for sure) there is an application specific interface that is used for communicating with the plugin. Such interfaces are good, just that you end up having to write application specific plugins. So plugins would be the first step to solve.
Next would be to try to make the parser of Quanta a loadable parser for KDevelop. This would be the hardest step, plus solving the problem of communicating with the parser in other plugins (like a plugin for the document structure view, autocompletion, etc.). Sincerely I don't have the slightest idea how it is done in KDevelop.
There are other features in Quanta that I don't really know how would them fit in the current KDevelop architecture.
Finally there are design (UI and code) decision that are different in the 3 applications, but this may be solved by discussion.
Now if we finally (some time in the future) could unify those application, then I still think that we shouldn't offer to the user just a shell that he can configure. We should offer preset "schemas" and maybe wrappers so when one calls this mega-application as "kate" it will load only the parts needed for advanced text editing, when one calls it as "quanta" only web and xml developing parts are loaded and so on.
Remember, there are applications which are highly configurable, act only as a shell and many users don't like them (like noatun). I also fear a little of such integrated applications.
Anyway, I don't see this happening soon. The best I can see is putting similar features in libraries or plugins so code can be shared. KMDI was a good example of such a codeshare.
Andras
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
