Patch is partly based on how WebCore works around those case. Looks as we have the same prob in 3.5. Ok to backport to 4.1 and 3.5?
CC_MAIL:kfm-devel@kde.org
svn path=/trunk/KDE/kdebase/apps/; revision=876130
Fix exit detection here, too, in case konqueror dies for some reason,
due to kill -9 or something. (Why else wouldn't it exit normally?)
svn path=/trunk/KDE/kdebase/apps/; revision=847206
Workaround a certain popular plugin's version 10 beta's inability
to figure out that 13 < 16.
(AKA, stub out some ABI r16 methods that get called despite us claiming only ABI r13 support.
I could perhaps do more than stubs, but I can't find any docs!)
BUG:164706
svn path=/trunk/KDE/kdebase/apps/; revision=825888
Work done by Sergey Saukh.
See discussion on kde-devel ('nsplugins patch (KDE4)').
CCMAIL:thelich@yandex.ru
svn path=/trunk/KDE/kdebase/apps/; revision=803987
non-Linux (ie. FreeBSD) systems.
Please find a more portable way of dealing with this library
CCMAIL: ahartmetz@gmail.com
svn path=/trunk/KDE/kdebase/apps/; revision=797567
(He didn't have time to make it yesterday and will able to commit it next thursday)
This patch clean up some :
target_link_libraries(kfoo kdeinit_kfoo) which is already done in kde4_add_kdeinit_executable()
macro and use "INSTALL_TARGETS_DEFAULT_ARGS" in other place.
I tested all compile file, all works fine but if there is a pb send me a mail.
CCMAIL: neundorf@kde.org
svn path=/trunk/KDE/kdebase/apps/; revision=795711
are two enum values of 13:
NPPVpluginKeepLibraryInMemory = 13, /* available in Mozilla 1.0 */
NPNVToolkit = (13 | NP_ABI_MASK),
and they are both used in certain switch statements; that's fine
as long as NP_ABI_MASK is non-zero, but for non-gcc compilers
it was, leading to compile errors in nsplugin.cpp (where it's weird
to have a switch on NPP* in a function that takes an NPN).
svn path=/trunk/KDE/kdebase/apps/; revision=790775
Ugh. Remember folks, always forwaport your changes.
FP r.565998, which fixes handling of redirects in nspv,
aka "Youtube videos embedded from an another page". Anyway,
I consider flash issues to be, to the best of my knowledge, resolved now.
BUG:132138
svn path=/trunk/KDE/kdebase/apps/; revision=769147
Make flash embedding work much better..
- Make sure to give distinct callback objects distinct IDs, so they
talk to the proper KHTMLPart. Fixes only one flash object working per
window
- Rework the size/init heuristics yet again, following closer to Seli's code,
but instead of trying to count events, etc., just have the part
tell us when we were really resized, and qwidget isn't making up a random
svn path=/trunk/KDE/kdebase/apps/; revision=768880
- Make the XEmbed host embed directly, removing 2 layers of embedding,
upon suggestion of Seli, hopefully making things more robust
- Be more careful in initializing the plugin, to avoid extra NPSetWindow calls
- Workaround Qt bug in the Xt host, to avoid annoying flicker of an unembedded
svn path=/trunk/KDE/kdebase/apps/; revision=768878
with XEmbed, so the XQueryKeymap() protection protected a bit too much.
The focus messages from QXEmbed are received only by the plugin itself
due to the way XSendEvent() is used, so forward focus in/out events
from the embedder side.
svn path=/trunk/KDE/kdebase/apps/; revision=764345
Thanks to his Xt event integration, I can now
implement (by c&p from old code, mostly) the Xt host.
Flash 9.0r48 seems to work now!
svn path=/trunk/KDE/kdebase/apps/; revision=748197
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
- Remove the padding hack now we're using newer headers
- Add some more compatibility features, such as initializing gtk for
plugins that need it. Also say we're keeping plugins in memory.
It's true, and swfdec-mozilla-0.5.3 wants it (though 0.5.4 does somehting else)
- Clarify some comments
- a bit of debug output
svn path=/trunk/KDE/kdebase/apps/; revision=748161
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
Fixup error logging (probably got broken in the port)
svn path=/trunk/KDE/kdebase/apps/; revision=748160
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
Update headers some more; this will make compat with things like swfdec a tiny bit easier;
though we'll likely have to work with them to get things working anyway
svn path=/trunk/KDE/kdebase/apps/; revision=748159
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
- Fix g_NPN_UserAgent to not return address of a temporary buffer
- Add some zeroed padding after the function table to provide some counter-sanity
against Flash reading npruntime functions for ABI revisions that don't
have them yet. Covers about 20 out of 2 zillion of vg warnings on it
... It would also help if XEmbed flash wasn't using Xt anyway, even w/XEmbed
svn path=/trunk/KDE/kdebase/apps/; revision=748158
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
Add beginning of an XEmbed host. It partly works --- youtube works part of the time;
but at least the playback window gets parented and sized properly
svn path=/trunk/KDE/kdebase/apps/; revision=748156
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
Update API header to provide the XEmbed variable names
svn path=/trunk/KDE/kdebase/apps/; revision=748155
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
Get the embedding of the viewer into part working (though it flickers a bit);
the plugin embedding itself not there yet
svn path=/trunk/KDE/kdebase/apps/; revision=748154
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
Fix confusion between part and viewer service IDs
(make the part's wrapper for the viewer's interface object
actually try to talk to the viewer)
Rename the relevant variables to reduce confusion
svn path=/trunk/KDE/kdebase/apps/; revision=748153
has the viewer <-> part interface mostly fixed, and
has beginnings of an XEmbed host for the plugin.
Unfortunately, that works part of the time at best
with r115, (probably none of the time on sites other than
youtube), and is quite crashy, partly because XEmbed flash
uses Xt anyway(!). I may have to go back to Xt only, not sure.
(Of course, Xt plugins don't work at all ATM). I need to consult
with some people on the best course of action, since this is getting very tricky,
and somewhat outside my area of expertise.
======================================================
The part is embedding the viewer, so this should be an XEmbed container..
svn path=/trunk/KDE/kdebase/apps/; revision=748151
- Remove some dead code that was making things even more confusing
- Remove debug output I accidentally committed
svn path=/trunk/KDE/kdebase/apps/; revision=728963
KConfigBase:
- remove separator argument from list entry reading/writing functions
- introduce {read,write}XdgListEntry()
- kill readPathListEntry(), add readPathEntry() overload
instead. the default value is not optional any more, as it defines the
return type. this is consistent with the readEntry() functions.
- rename clean() => markAsClean(), remove rollback()
- rename ConfigState => AccessMode, getConfigState() => accessMode()
- rename {entry,group}IsImmutable() => is{Entry,Group}Immutable()
- remove NLS alias to Localized
KConfig:
- remove setGroup() & group()
- reshuffle OpenFlag enum, introduce NoCascade for symmetry
- remove setExtraConfigFiles() alias to addConfigSources()
KConfigGroup:
- inherit KConfigBase::deleteGroup() overloads
- make convertToQVariant() private, it will probably change somehow
- KConfig & KConfigGroup: deprecate entryMap()
- remove bogus declarations: KConfigGroup::setReadDefaults(),
KConfig::readEntryUntranslated()
- apidox
- reshuffle the declarations in the headers
svn path=/trunk/KDE/kdebase/apps/; revision=728852
- Actually build a kpart and install as is.
- Actually build a working kcminit module. Which might not be
such a hot idea since KConfig seems to like to loop infinitely on this
stuff
- Actually let nspluginviewer start
Right now it's lost someplace in d-bus communication...
And we didn't deal with the Xt issue yet. Oh boy.
svn path=/trunk/KDE/kdebase/apps/; revision=728776
needed now because friday is the last BC day. The rest of the modules will
follow as fast as my laptop allows.
svn path=/trunk/KDE/kdebase/apps/; revision=721704
KDE4_ADD_TEST_EXECUTABLE is deprecated now use KDE4_ADD_EXECUTABLE(<target> TEST <files>) instead
QT4_ADD_DBUS_INTERFACE_NO_NAMESPACE and QT4_ADD_DBUS_INTERFACES_NO_NAMESPACE are deprecated too
used SET_SOURCE_FILES_PROPERTIES(<files> PROPERTIES NO_NAMESPACE TRUE) QT4_ADD_DBUS_INTERFACES(<srcList> <files>)
set( EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR} ) is put in each CMakeLists.txt where
KDE4_ADD_EXECUTABLE(<target> TEST <files>) and KDE4_ADD_UNIT_TEST were used.
svn path=/trunk/KDE/kdebase/apps/; revision=716149
of view, but it's completely unreasonable to expect the user to run
the check manually. Check timestamps to find out if a full scan is needed.
This also makes the config options for this more or less unnecessary.
BUG: 126744
svn path=/trunk/KDE/kdebase/apps/; revision=705275
into KParts::OpenUrlArguments and KParts::BrowserArguments.
This also allows the part to set arguments().mimeType() is the host didn't set it.
svn path=/trunk/KDE/kdebase/apps/; revision=699514
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
