svn::talk 0.0.1
Filter: muesli at gmail dot com 

222 commits found for author treat.
Mostly active for:   KDevelop   kdelibs   KOffice   kdebase

TimeProjectRevisionAuthorRepliesMessageFriday, 01. September 2006
04:44KDevelop579423treat5796* Temporary fix
01:32KDevelop579400treat28672Be quiet!
01:31KDevelop579399treat10235* Don't save window stuff to the project files. I don't think it makes sense, but perhaps it does. We'll reconsider when we get more advanced window stuff like perspectives. Currently a bug exists in that the window settings are not applied all of the time. It is hit or miss. Kudos to anyone who can spot the underlying bug...


TimeProjectRevisionAuthorRepliesMessageThursday, 31. August 2006
23:53KDevelop579388treat28463The initialization is in pretty good shape now. THe order of the objects initialized in KDevCore no longer matters.
19:39KDevelop579307treat0* More work on the initialization of kdevcore objects. Introduce a couple of methods for the objects to handle loading/saving their settings in different situations.


TimeProjectRevisionAuthorRepliesMessageWednesday, 30. August 2006
17:06KDevelop578950treat0Getting closer to kosher initialization. Suspend the weaver in construction and resume later after it has had a chance to see the project file settings. Reenable the progress bar.
16:38KDevelop578940treat0* We aren't using these at the moment so quit wasting CPU cycles building/linking


TimeProjectRevisionAuthorRepliesMessageTuesday, 29. August 2006
22:37KDevelop578683treat0Make all KDevCore objects implement the interface. Disable the progress bar in KDevBackgroundParser for now. Reimplement some stuff.
21:17KDevelop578663treat0Add a common interface for KDevCore objects. This should help sync the startup.
20:05KDevelop578629treat0Tired of installing these every time. We're not using them right now anyway.


TimeProjectRevisionAuthorRepliesMessageMonday, 28. August 2006
19:29KDevelop578252treat0* Make way for a new 'mode' button in the settings dialog. This new button will allow the user to specify which file to save the changes to. When a project is opened, the user can thus still save the changes to the local kdeveloprc file instead of the project file...


TimeProjectRevisionAuthorRepliesMessageThursday, 24. August 2006
20:10KDevelop576797treat0Add an option for number of threads, but disabled for now Waiting for threadweaver to allow setting number of threads for a created weaver object.
18:47KDevelop576750treat0Introduce a KCM for the backgroundparser. Next: add options for number of threads..


TimeProjectRevisionAuthorRepliesMessageWednesday, 23. August 2006
15:53KDevelop576251treat0Don't cache the factories per blackarrow and dfaure


TimeProjectRevisionAuthorRepliesMessageTuesday, 22. August 2006
23:59KDevelop576055treat0Add top-level UI mode and docked window mode to kdevelop 4. This should be roughly analagous to what designer 4 does. Right now, the top-level UI mode does not place the top-level windows in any kind of smart manner, but everything in time... Top-level UI mode should be good for Xinerama users and those who want a UI similar to designer or XCode. This patch completely changes the API for KDevMainWindow and how plugins are inserted into the UI. The API has been simplified and I've modified all the plugins to use this new API. Individual plugins that inherit KDevPlugin no longer need to worry about adding themselves and removing themselves from KDevMainWindow as this is accomplished by the plugin controller. However, individual plugins that inherit KDevPlugin and wish to have some sort of UI need to override a couple of new virtual functions in KDevPlugin. 1) virtual Qt::DockWidgetArea dockWidgetAreaHint() const; 2) virtual bool isCentralPlugin() const; 3) virtual QWidget *pluginView() const; The docs for these methods can be found in KDevPlugin. The quanta devs will want to modify their plugins to use this new API. In order to switch between UI modes, I've created a new KCM. In the future, this KCM might hold other UI options, like whether a taskbar entry should appear for plugin windows in top-level mode or whether the mainwindow should always stay on top... etc, etc. This is all still very rough, but you have to start somewhere, right? CCMAIL: kdevelop-devel@kdevelop.org


TimeProjectRevisionAuthorRepliesMessageSunday, 13. August 2006
17:23KDevelop572716treat0API cleanup
12:43KDevelop572633treat0Sync the dir on project open and close. Uncrustify a bit.
05:56KDevelop572535treat0Close all documents on project close. Save the recent projects to the right place. Fix a problem with closing docs in documentcontroller.
05:15KDevelop572534treat0Load the project after plugin loading and not vice versa This way when switching projects the global and core plugins don't have to be updated
04:01KDevelop572524treat0API cleanup
00:44KDevelop572511treat0StatusBar --> KDevStatusBar KDevStatusBar no longer displays doc info. Each document will have its own statusbar for this purpose. Just like kate. Makes sense for when we have top-level mode. Display the backgroundparser progress in the statusbar.


TimeProjectRevisionAuthorRepliesMessageSaturday, 12. August 2006
18:11KDevelop572452treat0


TimeProjectRevisionAuthorRepliesMessageFriday, 11. August 2006
15:12KDevelop572024treat0* Convert the config dialog to a tree heirarchy
03:49KDevelop571904treat0Show the window with no last project
03:42KDevelop571903treat0Make the environment kcm use the same lib as the other settings.


TimeProjectRevisionAuthorRepliesMessageThursday, 10. August 2006
18:03KDevelop571788treat0*Properly build and destroy the codeview
16:48KDevelop571771treat0Add a stub for KDevPeristentHash. It is just a stub for now because it requires google's sparsehash. It works, but I don't want to force everyone to install sparsehash until it is useful. KDevAST is now a struct and has a void* pointer for storing the associated memory pool. We'll probably want to store the memory pool in another way at some point Add some stub methods in KDevLanguagePart and the csharp language part for using the new serialize AST. An impl is provided in KDevLanguagePart for now so that C++ doesn't have to provide it. Provide actions for opening and closing projects.


TimeProjectRevisionAuthorRepliesMessageWednesday, 09. August 2006
16:40KDevelop571482treat0* Stars, baby. Stars.


TimeProjectRevisionAuthorRepliesMessageTuesday, 08. August 2006
22:41KDevelop571256treat0* Handle some real actions in the documentview context menu.
19:01KDevelop571197treat0Don't confuse reverting with reloading. Revert is something that SVN will do...
17:54KDevelop571177treat0Documentation fixes and updates
17:02KDevelop571163treat0* Fire up some context menus. We're using the same API to begin with althoug the signals originate from KDevMainWindow now.
16:08KDevelop571144treat0Use the 'triggered' signal, not toggled...
06:03KDevelop570934treat0Don't bug out on selection
06:03KDevelop570933treat0Hook up this signal properly
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
03:14kdelibs570916treat0Requested by numerous people. I respect that it is in the right debug area, but man that is a lot of output...
02:36kdebase570914treat0be quiet please
02:30kdelibs570912treat0shut up
02:30kdelibs570912treat0shut up
02:30kdelibs570912treat0shut up
02:30kdelibs570912treat0shut up
02:30kdelibs570912treat0shut up
02:30kdelibs570912treat0shut up
02:30kdelibs570912treat0shut up
02:30kdelibs570912treat0shut up
02:30kdelibs570912treat0shut up
02:30kdelibs570912treat0shut up
02:18KDevelop570911treat0Be quiet please
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:55kdelibs570898treat0quit spewing and put this in klibloader debug area
00:43KDevelop570897treat0Shut up and import c# and java in generic importer
00:42KDevelop570896treat0fix sig/slot connection


TimeProjectRevisionAuthorRepliesMessageMonday, 07. August 2006
16:23KDevelop570752treat0Revert commit #: 559299 559310 559317 558329 The ast members are initialized by the memory pool and if they aren't then it needs to be fixed in the memory pool. When initialized like this it makes the parser slower.
15:34KDevelop570729treat0* Remove the shared memory pools as per Roberto.


TimeProjectRevisionAuthorRepliesMessageFriday, 04. August 2006
18:58KDevelop569772treat0Optimize project loading, document loading, and background parser. 1. Introduce caching mechanism in the background parser and codeproxy. This allows us to perform an expensive operation only after a number of files have been parsed rather than for every file. 2. Part creation now caches the KParts::Factory(s) so we don't use KLibLoader for every creation of a document. 3. Change KDevDocument so that we cache information like the mimetype rather than looking it up by url every time. 4. Change the way we load KTextEditor documents at startup. Basically, KParts::openURL is expensive so we don't do that at startup. Instead this is done when the doc first becomes active. Will revisit this if it is too much of a delay for the user. 5. For the time being load every project file into the backgroundparser at startup. Use this to test for other machines. I want to see how long it takes. Some marks: With these optimizations I can load 1268 files (every c++ src/header file in kdevelop project) at startup as open documents in under two minutes. Each file is parsed and a codemodel is computed. Each file has a KTextEditor part created for it. And it takes about %32 of active memory once it is done. With no open documents at startup, I can still parse every file, all 1268, at startup in under 1 minute. That's pretty fast. Congratulations to Roberto and everyone else. CCMAIL:kdevelop-devel@kdevelop.org


TimeProjectRevisionAuthorRepliesMessageThursday, 03. August 2006
19:25KDevelop569418treat0Rework some of the slots in DocumentController and make the Kate modifiedOnDisc stuff
16:29KDevelop569361treat0Cleaning up documentcontroller a bit more
16:13KDevelop569357treat0KDevCore provides a set of fundamental objects for the KDevPlatform. These objects sometimes depend upon each other, but we can not know how an application will order the creation of the various objects. Because of this, all initialization of resources that depend upon one or more KDevCore objects should go in an 'initialize' method that is called by KDevCore::initialize(); Similarly, all cleanup of resources that depend upon one or more KDevCore objects should go in a 'cleanUp' method that is called by KDevMainWindow::queryClose(); Once this cleanUp is performed the objects can be safely deleted from KDevCore. CCMAIL: kdevelop-devel@kdevelop.org
15:33KDevelop569340treat0Fix the actions a bit more


TimeProjectRevisionAuthorRepliesMessageWednesday, 02. August 2006
16:56KDevelop569004treat0Get rid of mainwindowshare DPointerize KDevMainWindow 'Configure Project' when one is open


TimeProjectRevisionAuthorRepliesMessageTuesday, 01. August 2006
00:45KDevelop568401treat0Reduce the amount of compiler warnings in lib
00:05KDevelop568392treat0* reenable mainwindowshare until i have something better ;)


TimeProjectRevisionAuthorRepliesMessageMonday, 31. July 2006
23:50KDevelop568388treat0Merge kdev-its-gonna-be-great -r 565232:568297 into trunk CCMAIL:kdevelop-devel@kdevelop.org


TimeProjectRevisionAuthorRepliesMessageTuesday, 25. July 2006
20:27KDevelop566340treat0And we're parsing java files... :) All you need to start parsing java files is to change the line PrimaryLanguage=C++ in the global project file to PrimaryLanguage=Java. Right now the codemodel is not hooked up and the AST is not integrated. I don't think CMake knows how to deal with .ll files, so add the .cc file instead. The kdevelop-pg loads the _G_contents char array in a weird way. Need to change this so that it uses QByteArray or however the c++ parser does it. I commented out a few lines in java-io.cpp that were referencing main.cpp these methods in main.cpp need to be moved into a separate file if we want to keep them. Next steps would be to integrate the AST so that it inherits KDevAST and then we need to generate an actual codemodel that inherits KDevCodeModel. Once this is done, we'll be able to see the codemodel in the codeview :) Cheers,Adam CCMAIL:jpetso@gmx.at, kdevelop-devel@kdevelop.org
18:59KDevelop566309treat0Abstract the backgroundparser so it can be shared by multiple language parts. As mattr said, we don't need no stinking separate background parser for every piddling language part... Gosh!
15:38KDevelop566167treat0* Add the includes from kdevelop-pg and make the java parser build.
15:04KDevelop566157treat0And work ;)
15:03KDevelop566156treat0Now actually make it build
14:55KDevelop566155treat0* Manually add the java parser from kdevelop-pg to the java language part. In the future, we might make this a hard link, but for now jpetso will keep track of it. CCMAIL:kdevelop-devel@kdevelop.org
14:44KDevelop566151treat0* Begin the Java language support part while jpetso does the C# language support part! WOOHOO!


TimeProjectRevisionAuthorRepliesMessageSunday, 23. July 2006
01:29KDevelop565312treat0Oopsie


TimeProjectRevisionAuthorRepliesMessageSaturday, 22. July 2006
23:00kdelibs565281treat0Don't access the widget() unnecessarily
22:43KDevelop565274treat0Do lazy loading that katepart now provides Still need to edit KPartManager::addPart as it calls widget() prematurely
17:42KDevelop565207treat0clean-up
15:24KDevelop565165treat0Document the KDevEnv API. All plugins should now use this interface when using environment variables. All plugins should sync any spawned QProcess/KProcess with the variables found in this interface, as they were set by the user.
02:56KDevelop565007treat0The Environment widget settings dialog is now fully functional, but the KDevEnv API is not yet done. I neeed to add methods for syncing a QProcess/KProcess with the environment. I also need to document the API.


TimeProjectRevisionAuthorRepliesMessageFriday, 21. July 2006
22:11KDevelop564969treat0Getting very close to usable environment settings claass and dialog. Still need work on the API and documentation and the config dialog is not quite done.


TimeProjectRevisionAuthorRepliesMessageThursday, 20. July 2006
17:12KDevelop564637treat0Getting closer and closer to usable..
00:29KDevelop564370treat0Getting closer with the KDevEnv... A bit about this: KDevEnv will handle all the environment variable configuration for kdevelop and all of kdevelop's plugins. The configuration dialog will list all of the currently running process' environment variables and allow the user to add new variables or change existing ones. Any change the user makes will result in the actual process changing environment. All process' created from KDevelo should inherit this environment.


TimeProjectRevisionAuthorRepliesMessageWednesday, 19. July 2006
20:46KDevelop564310treat0typos
20:44KDevelop564309treat0* add some documentation to the new config framework * remove dumb setting in the global config file
20:23KDevelop564307treat0Move this where it belongs. I'm probably going to get rid of core.* and toplevel.* before too long. Again, for the near future, the only way to open a project in kdevelop4 is either via the command line OR setting this in your local kdeveloprc file: [General Options] Read Last Project On Startup=true Last Project=/home/kde/trunk/KDE/kdevelop/kdevelop.kdev4
20:13KDevelop564305treat0Lots of changes... Let's summarize: * Implement the new config framework. This means that project files are now INI style and split between a global FOO.kdev4 file that is safe to share, and a local .kdev4/FOO.kdev4 file that stores non-shareable settings like paths and environment variables. * Change CMake settings to use new config framework * Replace src/projectmanager.* classes with a projectcontroller.* class. Add a languagecontroller.* class that will allow more than one language part to be loaded at one time. * Add a kdevelop.kdev4 global INI project file that should be safe to share and commit to svn. Remove the old kdevelop4.kdevelop file. * For now, project loading only takes place via the command line OR if you have Last Project=/path/to/kdevelop.kdev4 file in your local kdeveloprc. I'm going to work on the action classes necessary to open projects soon ;) * Introduce a kdevenv.* class in lib/interfaces where all plugins that need access to the environment variables will get them. This means we'll no longer have separate plugins running with different variables and the user can expect to set/get env variables in one central KCM. You can get the environment from KDevApi... although it is not complete yet. * I'll be creating a tool to convert between kdevelop3 project files to kdev4 project files sooner or later.