I know that having a lower one is fine --- it implies potentially
smaller function structures, and higher version may require implementing
more stuff. The reason I asked is that I did something similar internally
when working on npruntime support, and I know flash 7 would crash with
some value of NP_VERSION_MINOR, but I am not sure whether it was 13 or 14.
svn path=/trunk/KDE/kdebase/apps/; revision=665308
Don't use long for 32 bit types on LP64 platforms.
Now Konqueror can use e.g. flashplugin on x86_64 with nspluginwrapper :-)
svn path=/trunk/KDE/kdebase/nsplugins/; revision=655588
returning void* for functions is bad - so introduce
resolveFunction() and resolveSymbol() to make this separation
clear.
svn path=/trunk/KDE/kdebase/nsplugins/; revision=649230
KShellProcess -> K3ShellProcess
KProcIO -> K3ProcIO
KProcessController -> K3ProcessController
not deprecating, as we don't have a replacement yet.
not moving yet, as kdelibs still has heavy dependencies on it.
agreed upon with dfaure.
svn path=/trunk/KDE/kdebase/nsplugins/; revision=646732
some module compiles with enable-final now)
As discussed with Alex it's not necessary to have program name
into automoc macro
svn path=/trunk/KDE/kdebase/konqueror/; revision=598290
enable-final argument
(there was not a dependancy between <name>_final.cpp file and
moc generated files => moc files were never created)
Not necessary to rebuild all kdelibs just cp kdelibs/cmake/modules/KDE4Macros.cmake <path_kde4>/share/apps/cmake/modules
I ported and tested all kde module (without enable-final argument, it compiles fines (test and program))
Don't try to use enable-final argument for the moment it doesn't compile (but dependancy works)
Regards
svn path=/trunk/KDE/kdebase/konqueror/; revision=595039
became a bit larger than expected, so I couldn't have the time
to check if it still compiles with the changes done in between
svn path=/trunk/KDE/kdebase/kdepasswd/; revision=578269
Remaining errors consist only of #include not found (dcopclient.h, dcopref.h, kdatastream.h and kdirnotify_stub.h)
svn path=/trunk/KDE/kdebase/nsplugins/; revision=548395
-cleanup the toplevel CMakeLists.txt a bit
-remove include_directories( CMAKE_CURRENT_SOURCE_DIR CMAKE_CURRENT_BINARY_DIR)
in the subdirs, since this is done now automatically by cmake (the CMAKE_INCLUDE_CURRENT_DIR option
-include_directories(KDE4_INCLUDES) in the toplevel CMakeLists.txt, so it
doesn't have to be done in every subdir
Alex
svn path=/trunk/KDE/kdebase/konqueror/; revision=539914
Better error message when Xt isn't available (in fact this makes it optional, to avoid a cryptic error message)
svn path=/trunk/KDE/kdebase/nsplugins/; revision=536355
${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR} in each and every file anymore [only when subdirs might depend on that].
Also ran a script which makes sure that ${KDE4_INCLUDE_DIR} and ${QT_INCLUDES} are added -last-,
so that installed headers are not preferred over (possibly more uptodate) local headers.
svn path=/trunk/KDE/kdebase/konqueror/; revision=521887
BE CARREFULL: Don't try to compile it for the moment (in progress)
Don't use kdelibs trunk for compile it (there is not again test to disable
compile when we compile with kdelibs trunk)
For the moment there was a lot of missing test etc.
I commit it just to allow to lose my changes if there is a pb on my HD.
I will sync cmake from kdelibs trunk to kdelibs-snapshot.
I hope to fix compile today or tomorrow.
CCMAIL: neundorf@kde.org
For the futur we must sync kdelibs/cmake/* to kdelibs-snapshot
to compile all the time with kdelibs-snapshot
svn path=/trunk/KDE/kdebase/konqueror/; revision=514380
altogether instead. Haven't tested compile of this since my trunk checkout and
build is far too old now.
svn path=/trunk/KDE/kdebase/nsplugins/; revision=506585
-Replace QXEmbed with QX11Widget in nspluginloader and viewer.
-Commented out some parts that need port/rewrite with "#if 0" (I put #warning)
-Put klipper into DO_NOT_COMPILE(see configure.in.in), it make linking error on my setup (please check KDE gurus ;))
svn path=/trunk/KDE/kdebase/nsplugins/; revision=442846
svn+ssh://coolo@svn.kde.org/home/kde/branches/work/kde4/kdebase
.
I couldn't resolve one kicker conflict that results from different
development directions, so I rely on Aaron to sort it out - the file
is commited with conflicts
svn path=/trunk/KDE/kdebase/konqueror/keditbookmarks/; revision=439627
UI option if and when I receive positive feedback that this code works.
I haven't tested it.
FEATURE: 104338
svn path=/trunk/KDE/kdebase/nsplugins/; revision=415756
should reload subsequent requests by the plugin though. I'm going to declare
that to be a limitation of the plugin system design right now. (unless I missed
something)
BUG: 86476
svn path=/trunk/kdebase/nsplugins/; revision=393056
I don't even plan to use this feature personally. If someone wants to,
clean it up.
Off by default, configuration option to come shortly.
FEATURE: 36020
svn path=/trunk/kdebase/nsplugins/; revision=393042
is killed with signal 9 or another signal that nspluginviewer doesn't detect.
This really should be in 3.4.0 so I recommend applying the diff for packages.
CCMAIL: kde-packager@kde.org
svn path=/trunk/kdebase/nsplugins/; revision=393025
resize it twice. First we do show(), then resize() to the right size, and the
initial show gives a size of 100x30. The result was quicktime being offset by
some strange amount to the top-left. This patch avoids resize()ing the plugin
when the widget isn't yet visible.
CCMAIL: fgouget@codeweavers.com
svn path=/trunk/kdebase/nsplugins/; revision=391684
(Distros, you may want to backport some or all of this. It makes flash loading
screens work again, and probably many other things.)
BUG: 69999
svn path=/trunk/kdebase/nsplugins/; revision=391653
it later tonight. I haven't tested this since I don't really have any working
plugins with me at the moment.
FEATURE: 83721
svn path=/trunk/kdebase/nsplugins/; revision=362419
are correctly preseved. On the other hand, a : too much can break a lot of the
following logic. And for whatever reason Real decided to name their plugin
"Helix DNA Plugin: RealPlayer G2 Plug-In Compatible ...."
svn path=/trunk/kdebase/nsplugins/; revision=357560
Of course, this will multifold break compile as well as a dozen of people
will now object that they actually wanted the Id tags.
svn path=/trunk/kdebase/konqueror/; revision=290873
be implemented in embedded mode due to semantics, though theoretically it
*could* be done if someone made a submenu that listed all the embeds and had
menus for each of those. Not worth it IMHO, so that's a WONTFIX as far as I'm
concerned.
CCMAIL: 71023-done@bugs.kde.org
svn path=/trunk/kdebase/nsplugins/; revision=282888
install location accordingly.
I'm backporting this too.
Patch approved by David Faure on kde-core-devel.
CCMAIL:"Christopher L. Cheney" <ccheney@debian.org>
svn path=/trunk/kdebase/nsplugins/; revision=282461
Config GUI will come separately. This will allow you to block plugins from
accessing non-HTTP(S) URLs optionally.
CCMAIL: 62146-done@bugs.kde.org
svn path=/trunk/kdebase/nsplugins/; revision=253641
This is supposed to make Konqueror not block when closing a page with a frozen plugin.
CCMAIL: 47005-done@bugs.kde.org
svn path=/trunk/kdebase/nsplugins/; revision=246073
- Only add plugins that we are using mimetypes from
- Fix the mimeinfo list so that duplicate detection actually works
- If we already have a mimetype, don't add it again. This make preference
order work as expected (#60553). Requires a rescan to take effect.
Most likely will not be backported because I want to see if there are any
complaints, and well, it worked before anyways.
CCMAIL: 60553-done@bugs.kde.org
svn path=/trunk/kdebase/nsplugins/; revision=238051
Nspluginviewer is only a helper tool and not a full application,
and therefoce it shouldn't do session management at all.
svn path=/trunk/kdebase/nsplugins/; revision=222908
for Qt's initial resize to 100x30. Some plugins don't like resizing so many
times, or even resizing at all.
svn path=/trunk/kdebase/nsplugins/; revision=211687
plugin loads and operates as well as Crossover. The new approach is to set
the canvas to 1600x1200 if the size is unspecified (this works around
Crossover problems with resizing to larger than the original canvas setting),
but telling the plugin that it is 0x0, which is what some plugins expect. It
seems that all plugins can scale upwards, but many have troubles scaling down.
That being said, the trailers on apple.com still don't work, but it appears to
be mplayer specific now. I think mplayer is actually crashing, but even if not,
it's giving a lot of errors in the console. The trailer shows up momentarily
as a very small video in the top-left of the view, then just disappears
silently. Playing local files works fine (.wmv, .mpg, .mov, etc).
Hopefully this patch finally makes everyone happy. I have successfully tested:
flash6
realplugin
mplayerplugin
crossover
djvu
tclplug
acrobat plugin
swfdec mozilla plugin
Remains to be tested: plugger (if it's even worth it...)
And they all seem to work well now. I can't find many problems other than the
missing jre which is probably not going to be solved any time soon (so no
real live connect support). I would like to backport the changes from the past
5-6 days to the 3.1-branch. I'll do so tonight if I don't hear any negative
feedback.
CCMAIL: j.spaandonk@chello.nl, kdekorte@yahoo.com, fgouget@codeweavers.com, kfm-devel@mail.kde.org
svn path=/trunk/kdebase/nsplugins/; revision=211605
anyways), we are now the only browser to support this. I don't really have
anything else handy to try it.
svn path=/trunk/kdebase/nsplugins/; revision=211454
because there is no way to access the callback in this method. NS did not
provide the private data here...
svn path=/trunk/kdebase/nsplugins/; revision=211397
Some plugins don't resize when the motif canvas resizes. So what we do is
resize them ourself by walking the window tree underneath the canvas and
explicitly XResizeWindow()ing whatever we find.
Please test with all your favorite plugins to see if I broke or fixed
anything.
CCMAIL: 39685-done@bugs.kde.org
svn path=/trunk/kdebase/nsplugins/; revision=211381
See before and after on:
http://examples.macromedia.com/petmarket
(must have Flash 6)
This does not handle POST where the data gets returned anywhere except back to
the plugin. That is, it doesn't allow the post results to appear in a browser
frame yet. This is because I left:
// FIXME
there which of course doesn't do much. It's all documented though. Also
these functions only support "http" and "https" and nothing else. I have no
personal intention to go any further with this, but I think it's supposed to
be possible to do other URLs too, at least that's what I figured from reading
the specs.
One other thing that does not work is plugins which put the POST data in a file
and pass the file name in to be POSTed. I just haven't written the header
parser here. If you find a site that uses it, show me, send beer/pizza, and
I'll do that for you too.
CCMAIL: kfm-devel@kde.org, 49746-done@bugs.kde.org
svn path=/trunk/kdebase/nsplugins/; revision=210340
Also fix my previous memleak fix to check for null before calling free().
And one for the record books:
==31591== 144000 bytes in 12 blocks are definitely lost in loss record 198 of 20
0
==31591== at 0x401676C8: malloc (vg_clientfuncs.c:100)
==31591== by 0x46BD5128: (within /opt/netscape/plugins/old/libflashplayer.so)
==31591==
==31591== 24912000 bytes in 108 blocks are possibly lost in loss record 200 of 2
00
==31591== at 0x401676C8: malloc (vg_clientfuncs.c:100)
==31591== by 0x46BD5128: (within /opt/netscape/plugins/old/libflashplayer.so)
If I let it run longer, it just keeps expanding.
svn path=/trunk/kdebase/nsplugins/; revision=210313
- small optimisation
- comment to avoid future problems
- trap javascript:history.back urls and use browserInterface instead, since
KIO::get() doesn't work for these urls. Fixes crossover from kfmclient.
(this all may be backported as well)
svn path=/trunk/kdebase/nsplugins/; revision=210291
It appears that the plugin was not getting destroyed until after the drawing
area was, if at all!! I'm not sure why this was removed, nor am I sure why
the plugins were deleted in a [single shot equivalent] timer instead of
immediately.
This is just a workaround the timer code for now. I'll clean it up later if
this is a good fix. It still seems to grow without bounds, but that might be
a flash bug as much as anything. I think it might be reasonable to put a
death counter in nspluginviewer and kill it off after n plugin loads, just
to be safe. Anyone against that?
CCMAIL: kfm-devel@mail.kde.org, hetz@kde.org
svn path=/trunk/kdebase/nsplugins/; revision=210199
temporary workaround and see what the response is. I was able to let it run for
quite a long time, probably viewing hundreds of flashes in the end, and it was
rock solid, but did leak a lot of memory. Luckily the viewer is killed off
rather quickly so we dont' have much to worry about. Now, does anyone know
Xt and Xm well enough to debug this? I know exactly what the problem is, but
I don't know why, nor how to fix it. Anything I tried causes crashes or big
memory leaks.
svn path=/trunk/kdebase/nsplugins/; revision=209522
I think it will do the post ok, but it won't return the results as it is
supposed to, and only http/https urls work.
CCMAIL: 49746@bugs.kde.org
svn path=/trunk/kdebase/nsplugins/; revision=208496
flash intensive pages (with 10 flash animations), these blocking
calls made up 90% of the page loading time.
Replaces the sleep calls with usleep to at least get the time
things are blocking down significantly.
IMO we really need a non blocking solution here.
svn path=/trunk/kdebase/nsplugins/; revision=186013
KDE I had to change to get it working with 3.1, as the Xt integration
relied heavily on Qt internals that have changed between 3.0 and 3.1.
We now use a QXtEventLoop to to the event loop merging, simplifying the
code when compiling against Qt-3.1. The old code is still there.
I tested it a bit against 3.1, and it seems to work nicely. We'll see
the real problems after the beta is out ;-)
svn path=/trunk/kdebase/nsplugins/; revision=173291
use glibc (*BSD for example) __GNUC_PREREQ seems to be a glibc feature,
and not always available on other systems.
I've renamed my macro to *hopefully* avoid name clashes.
-#if defined(__GNUC__) && __GNUC_PREREQ(3,0)
+
+#if defined(__GNUC__) && defined(__GNUC_MINOR__)
+#define KDE_GNUC_PREREQ(maj,min) \
+ ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
+#else
+#define KDE_GNUC_PREREQ(maj,min) 0
+#endif
+
+#if defined(__GNUC__) && KDE_GNUC_PREREQ(3,0)
svn path=/trunk/kdebase/nsplugins/; revision=166365
also applies to any other coordinate based things that the plugin does.
This is a 3.0.3 candidate as well. This in conjunction with QXEmbed changes
should fix most outstanding bugs in nsplugins. Now it's safe to add more
features I think.
CCMAIL: kfm-devel@mail.kde.org
svn path=/trunk/kdebase/nsplugins/; revision=165667
- Don't create mimetype .desktop files with Patterns=*.* when a nsplugin
says it's associated with extenstion=* (ouch!)
svn path=/trunk/kdebase/nsplugins/; revision=154547
We will have to come up with a better solution in 3.01/3.1 for detecting when
nspluginviewer crashes.
svn path=/trunk/kdebase/nsplugins/; revision=143495
crash, though. This time it was due to (a) free/delete mismatch and (b) double
delete of the same object that was mismatched (!!)
Crossover still works as before, as does flash. Adobe Acrobat doesn't freeze
nspluginviewer in free() anymore, but it still returns error after it has been
loaded multiple times in the same viewer process. I'm not sure why, but the
error code is NPERR_GENERIC_ERROR IIRC.
Flash still crashes and/or freezes on www.dreamworks.com in the Time Machine
section (very reproducible), but it also crashes in NS 4.x so that's not our
fault.
--- nsplugin.cpp 2002/03/15 17:47:53 1.68
+++ nsplugin.cpp 2002/03/16 16:04:59
@@ -395,7 +395,7 @@
XtDestroyWidget(_form);
XtDestroyWidget(_toplevel);
- ::free(_npp);
+ ::free(_npp); // matched with malloc() in newInstance
_destroyed = true;
}
@@ -932,7 +932,10 @@
char mime[256];
strncpy(mime, mimeType.ascii(), 255);
mime[255] = 0;
- NPP npp = new NPP_t;
+ NPP npp = (NPP)malloc(sizeof(NPP_t)); // I think we should be using
+ // malloc here, just to be safe,
+ // since the nsplugin plays with
+ // this thing
npp->ndata = NULL;
// Create plugin instance object
@@ -953,8 +956,8 @@
if ( error!=NPERR_NO_ERROR)
{
delete inst;
- delete npp;
- kdDebug(1431) << "<- PlluginClass::NewInstance = 0" << endl;
+ //delete npp; double delete!
+ kdDebug(1431) << "<- PluginClass::NewInstance = 0" << endl;
return DCOPRef();
}
svn path=/trunk/kdebase/nsplugins/; revision=143281
1) Make a workaround to get crossover to work until it is fixed properly. It
appears that the problem is a bug inside crossover. (I _think_. Will contact
them soon.)
default w,h of (300,300) is now (1600,1200).
If you have a bigger monitor, well, tough. :)
This doesn't mean that you get a 1600,1200 window. It gets resized down
immediately before it is shown.
2) Make konqueror/khtml not freeze if a plugin crashes. If you dont' believe
me, check www.dreamworks.com and look at the trailer of the time machine movie.
It's a flash movie and it crashes in both NS and Konqueror with my flash
plugin. This patch lets konqueror keep on working.
k_dcop:
- virtual void shutdown() = 0;
+ virtual ASYNC shutdown() = 0;
3) Add an unused parameter to the NSPluginInstance so we can know if it's
supposed to be an embedded widget or not. This will make it possible to at
one time have completely external plugins that work -- I hope.
Approved by hetz and David.
Now Quicktime works. MS Media doesn't embed, but works nonembedded. I think
this is a crossover problem too since the "please purchase" window works just
fine. Flash plugin works as always.
svn path=/trunk/kdebase/nsplugins/; revision=143164
- if (!strcasecmp(_argn[i], "HEIGHT")) height = atoi(_argv[i]);
+ if (!strcasecmp(_argn[i], "WIDTH")) width = argv[i].toInt();
+ if (!strcasecmp(_argn[i], "HEIGHT")) height = argv[i].toInt();
yeah lots more that could be Qtified too.
svn path=/trunk/kdebase/nsplugins/; revision=143050
+ kdWarning() << "Plugin doesn't implement NP_GetValue" << endl;
seems to be the case with the realplayer plugin (the last stable, not the
new beta), which breaks sites using JS to list the plugins....
svn path=/trunk/kdebase/nsplugins/; revision=137204
Changelog:
Provide a correct 'end' in all stream related NPP calls.
Provide a correct mimetype in streams created by NPP_GetURL.
Switch to new method for determining default User Agent.
svn path=/trunk/kdebase/nsplugins/; revision=115689
with the forked process through pipes. This patch doesn't rely on the pipe buffer anymore
nor uses select() -- but a simple blocking read from the pipe.
svn path=/trunk/kdebase/nsplugins/; revision=114437
file. This is because KTempFile doesn't allow upper case X as a
character yet *some* filenames have this.
svn path=/trunk/kdebase/nsplugins/; revision=110062
hacky and results in a memory leak... and completely stops the
segfault when linked with libGL. Memory leaks during releases are
bad, but nowhere NEAR as bad as crashes!
After 2.2, this needs to be fixed for real.
svn path=/trunk/kdebase/nsplugins/; revision=108532
