faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
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. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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)
