On Saturday 19 March 2005 16:48, Tobias Koenig wrote: > > attached is a first idea of how the KRES::Resource class should look > like in KDE 4.0. > > I tried to design it concerning the two most important needs: > asynchronous access and a constraining API, so that the people which > have to implement the subclasses can't do anything wrong (that is a main > problem with the current version). Requiring to call the emit functions instead of emitting the signals directly doesn't meet the goal of preventing the user from doing something wrong. An alternative might be to delay the actual call of the do* functions and immediate error reporting until the code has returned to the event loop. So we wouldn't need the emit* functions but still could make sure that the signals aren't emitted during the load/save/open/close calls. > I left out the 'configuration' stuff ATM, because we should discuss this > a bit more in detail. IMHO the resource should be 'configured' by an > external class like 'ResourceManager' and not read/store the > configuration itself. What about the identifier, name, type, read-only information? This belongs to the Resource class even if we do the config handling externally. The active state should be handled externally, in my opinion, as it would make it possible to have different active (or other) states of the same resources for different applications. Another problem we might want to address is the semantics of open/close in relation to load/save. This isn't too well-defined right now. How is open actually used? In practice I experienced more problems than benefit from having separate calls for open and load. -- Cornelius Schumacher _______________________________________________ kde-pim mailing list kde-pim@kde.org https://mail.kde.org/mailman/listinfo/kde-pim kde-pim home page at http://pim.kde.org/