From 3b1405169d66e029912f53d10c2880c46f5ed159 Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Wed, 16 Nov 2011 13:51:39 -0600 Subject: Additional renaming of kde to tde --- kparts/COMMENTS | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'kparts/COMMENTS') diff --git a/kparts/COMMENTS b/kparts/COMMENTS index e3e4d8589..80e5671d1 100644 --- a/kparts/COMMENTS +++ b/kparts/COMMENTS @@ -28,7 +28,7 @@ In this case, yes, that could be saved in the part. -------------- 4) Perhaps a part wants to know if it got activated, so we might want to - re-introduce that PartActivateEvent from kdelibs/kparts. + re-introduce that PartActivateEvent from tdelibs/kparts. Question: Shall this event be sent when the GUI of the part is activated or shall it be sent when the part "really" got activated (via KPartManager)? @@ -90,7 +90,7 @@ it is embedded (with or without GUI items). Hmmm.. Loading and saving in that case would mean save/load the view profile. (David) Hmmm... somebody wanting to embed a full konqy ? Component technology allows -you to avoid duplicate code by embedding a component that does what you want. Like kdevelop +you to avoid duplicate code by embedding a component that does what you want. Like tdevelop embeds a kedit component. Which app would want to embed a huge component containing a file maneger + a web browser + a generic viewer + ... ? I think this is not a component, but an application. Views are components... @@ -140,7 +140,7 @@ the whole, at other places). (David) Depends how we want to handle the popupmenu in KonqHTMLView, for instance. At the moment it's missing, and it will be a problem when that view is moved to -kdelibs : no more libkonq for it. But anyway I agree : the part should +tdelibs : no more libkonq for it. But anyway I agree : the part should generally take care of its own menu (I'm thinking of KNotePadPart for instance) Perhaps this would remain in KBrowserPart though (we need it in konqueror). @@ -331,7 +331,7 @@ changes. well I think _yes_ you would expect its actions to become available to the user, no ? dfaure: Imagine you write a report generator that shows database queries using the browser view. Would you as a programmer want to have menu entries like "OpenURL" and "History" in your report generator? I would not. hmmm ... then it's the HTML widget you're using, not the part... - when kdevelop embeds kwrite, it wants the actions from kwrite... + when tdevelop embeds kwrite, it wants the actions from kwrite... open file, save file, ... dfaure: Well,. why not load a HTML widget at runtime as a part ... sure, why not :-) -- cgit v1.2.1