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
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
