From quanta-devel Mon Jul 25 18:48:02 2005 From: Jens Herden Date: Mon, 25 Jul 2005 18:48:02 +0000 To: quanta-devel Subject: [quanta-devel] Quanta and the KDevelop framework Message-Id: <200507260148.02854.jens () kdewebdev ! org> X-MARC-Message: https://marc.info/?l=quanta-devel&m=112231862909986 Hi all, this mail is somewhat longer and is the essence of my attendance at the KDevelop conference in Kiev and my hacking meeting with Andras here in Romania. I am about to go back to Cambodia and we will summarise our problems in using the KDevelop framework we found so far in this mail. But I want to start with saying that we are very happy with the framework and we could quite easily port Quanta code to KDevelop. We were able to produce a first working version during the last six weeks (see branches/work/kdevquanta in SVN). When we started we were not sure if we could reach such a good result. So thumbs up for KDevelop and now the list of open questions and requests for changes. Please bear in mind that all this is targeted for KDevelop 4.0. We are not quite sure how we want to procede with this list. Our plans are to release a first test version of what we did together with Quanta 3.5 and we plan to create the first real release for KDE 4.0 This means we will not join yet the KDE 4.0 development until 3.5 was released. So we can start working on the mentioned issues then or other people can pick up them yet already. 1. create a new file that is not in the filesystem We miss a way to open a new file without creating it in the filesystem. We found an ugly workaround that does not really work nice. Our wish would be to pass an empty KURL to open a new texteditor. 2. remote file or projects The framework use QStrings to store an absolute path for files or folders. This prevents us from creating remote projects. The framework should use KURL for all absolute paths. E.g. in KDevProject the method projectDirectory should return KURL, isProjectFile() and relativeProjectFile() should use KURL. The first argument of openProject() should be KURL. 3. additional methods for the project handling We could not find a method to close the open project and one to save the open project. Saving a project can be usefull after changes in the settings. 4. more signals in the interface We would like to have new signals for aboutToSaveFile, aboutToCloseFile and aboutToCloseProject. 5. events Quanta has a feature to create and react on special events inside of the application. We would like to implement a similar feature in the framework. It would work with QCustomEvents and would allow plugins to filter and react on events. 6. one URL in more than one part The framework assumes that only one part can open the same url at the same time. This is a limitation which we must remove for Quanta, because the same document can be in the editor, the preview and a link checker at the same moment. 7. support for different kparts in the framework For opening an url it is not enough to pass the url, we also need a way to specify which kpart should open this url. This means also we need to be able to find out which kpart has opened an url and save this information. 8. disable plugins without the profile editor currently the user can disable plugins when he/she uses a project but since Quanta does not depend on a project it would also be important to disable plugins without an project. A kind of dialog that only allows to disable plugins from the current profile. 9. splash screen text has hardcoded colors The splash screen class does not use the provided color parameter to render the text message. 10. problem with configuration dialog The config dialog does not display the first page, if the extension does not provide a global page for the application. 11. modified on disc The framework uses the kate part to get information if a document was changed on the disc. This does not work if no Kate part is used. The framework should detect this on its own. The message about a change in disk does appear when the user saves the document. We would suggest to show this message when the document get the focus instead. 12. context menus The current implementation for the context menu does allow to add entries to popup menus from other plugins. This works nice so far but has the problem that we do not know the source plugin. So we are not able to conditionaly show an entry for a file context. E.g. the tabbar has file context but we would not like to pollute this menu with all file context actions. 13. open project dialog The extensions in the open project dialog are hard coded. Since we want to use ".quanta" as a new file extension with the KDevelop data structure internally we need a way to set the filter for the dialog to something else. We are looking forward to a fruitfull cooperation Jens _______________________________________________ quanta-devel mailing list quanta-devel@kde.org https://mail.kde.org/mailman/listinfo/quanta-devel