There is no way to close impress remote if you accidentally open it. Close button doesn't work.
I can confirm in Beta2 too, I just selected that menu item by mistake and had to kill Impress as a whole, very bad if I would had my work unsaved. Here 4.0beta2, GNU/Linux debian sid 64, KDE as DE
I can confirm in night build 2/Jan/2012 mac os x version, too. mac ox x ver 10.7.5
This closes just fine for me - both with the close button and the X tick at the top right using a libreoffice-4-0 build from just after rc1. Can you confirm that this continues to be a problem with RC1 ?
I've just installed LiBo4.0RC1, and the bug is still there
I also installed RC1 and the bug is still existing.
Still doesn't close in RC1 for me too. Reopening the bug.
Tricky but I think I'm marking this as NEW as three users are reporting the issue. Michael - any idea what could make it not work for three people but works fine for you? Marking as NEW (confirmed) I tend to agree that this is a CRITICAL bug as the inability to close would be a big problem, especially for a new feature. Curious to know what's going on that's unique to your environments that would cause this issue. Can you give us more details about your setups?
Can someone attach a screenshot of what is not closing ? :-) I have seen a deadlock when using the remote that I'd like to nail-down as well. As/when this happens - can you please do: $ pidof soffice.bin $ gdb attach <pid printed out above> thread apply all backtrace and append the result here ? then we can nail it I think. We really need the debuginfo packages installed to do that - but if you don't have them any sort of trace -may- help. Thanks !
Created attachment 73636 [details] Screenshot of what is not closing
Created attachment 73637 [details] Trace Added trace as Michael requested. Using RC2, without any LibO debug packages (do the pre-releases / daily builds from http://dev-builds.libreoffice.org/ have them at all?).
Created attachment 73638 [details] trace from GNU/Linux 64, LiBo RC2
Created attachment 73639 [details] Trace when I tried to close the program and was not responding
Created attachment 73640 [details] Video showing the problem GNU/Linux 64, LiBo RC2 Here you can see the exact steps and what happens :)
http://cgit.freedesktop.org/libreoffice/core/commit/?id=e99b540d8985b87247519c951e6ef65a01b1f5c9 Is a memory corruption related to that sdremote dialog that may cause something like this issue - I'd love a test of a recent master build with that fix included.
I would test it, but the newest build LO 4.0 still has this bug and there is not master build for Linux 32bit (deb package). Could anyone else test it
Anyone else to test it ? the suspected fix went into the -4-0-0 branch just now - so should be in rc3.
(In reply to comment #16) > Anyone else to test it ? the suspected fix went into the -4-0-0 branch just > now - so should be in rc3. Michael, there still is a bug. Tested on libreoffice-4-0~2013-01-29_23.13.14_LibO-Dev_4.0.1.0_Linux_x86_deb.tar.gz
(In reply to comment #16) > Anyone else to test it ? the suspected fix went into the -4-0-0 branch just > now - so should be in rc3. Can confirm this is still reproducible. Therefore back to ... NEW (or REOPENED, still need to discuss this kind of specific situations on the QA call).
*** Bug 60325 has been marked as a duplicate of this bug. ***
I can confirm this bug in LibreOffice_4.0.0.3_Linux_x86_deb
My strong suspicion is that this is KDE specific; can someone that can repeat the problem do: export SAL_USE_VCLPLUGIN=gtk pkill -9 -f soffice.bin soffice -impress and see if the problem recurs ?
(In reply to comment #21) > My strong suspicion is that this is KDE specific; can someone that can > repeat the problem do: > > export SAL_USE_VCLPLUGIN=gtk > pkill -9 -f soffice.bin > soffice -impress > > and see if the problem recurs ? It can't be. I am using Ubuntu 10.04 LTS with GNOME 2.30.2. Besides, Your approach doesn't work.
> It can't be. I am using Ubuntu 10.04 LTS with GNOME 2.30.2. > Besides, Your approach doesn't work. Seriously ? that's bad... So - we need someone that can reproduce this that is a developer; it works perfectly for me, and Thorsten, the code seems reasonable too. The dialog in itself is profoundly non-useful - so one (non-ideal) workaround is just not to launch it ;-) But it is deeply annoying that this is not reproducible everywhere; perhaps a trace with more debuginfo would be interesting ? but really it's just that the dialog is not closed - 'Execute' never completes (I suspect) - so the question is: why !?
Wow - so, this looks rather bad. It -seems- that the code path is missing some: #ifdef ENABLE_SDREMOTE code-path - which is horrible ! it looks like we simply havn't enabled the sdremote (or bluetooth) in the builds [!!].
source/ui/dlg/tpoption.cxx-#ifndef ENABLE_SDREMOTE_BLUETOOTH source/ui/dlg/tpoption.cxx: aCbxEnableSdremote.Hide(); source/ui/dlg/tpoption.cxx-#endif And I can see -no- mention of the expected: source/ui/dlg/tpoption.src: CheckBox CBX_ENABLE_SDREMOTE source/ui/dlg/tpoption.src- { source/ui/dlg/tpoption.src: HelpID = "sd:CheckBox:TP_OPTIONS_MISC:CBX_ENABLE_SDREMOTE"; source/ui/dlg/tpoption.src- Pos = MAP_APPFONT ( 12 , 158 ) ; source/ui/dlg/tpoption.src- Size = MAP_APPFONT ( 242 , 10 ) ; source/ui/dlg/tpoption.src- TabStop = TRUE ; source/ui/dlg/tpoption.src- Text [ en-US ] = "Enable remote control" ; source/ui/dlg/tpoption.src- }; in the impress 'General' options page (underneath 'Always with current page') in Tools -> Options -> LibreOffice Impress. ie. that is -certainly- not defined.
(In reply to comment #23) > > It can't be. I am using Ubuntu 10.04 LTS with GNOME 2.30.2. > > Besides, Your approach doesn't work. > > Seriously ? that's bad... So - we need someone that can reproduce this that > is a developer; it works perfectly for me, and Thorsten, the code seems > reasonable too. The dialog in itself is profoundly non-useful - so one > (non-ideal) workaround is just not to launch it ;-) > > But it is deeply annoying that this is not reproducible everywhere; perhaps > a trace with more debuginfo would be interesting ? but really it's just that > the dialog is not closed - 'Execute' never completes (I suspect) - so the > question is: why !? One general suggestion to developers: use virtual machines! For testing I use KVM with some stock distro installed, and/or live cd with enough ram assigned (is used as hard disk, you need a lot to let the Libo packages be uncompressed and installed). I'm a KDE fan, but I've just downloaded (since you had some dubt about KDE): ubuntu-12.04.1-desktop-i386.iso run with KVM and 2GB of ram, inside the vm I downloaded the RC3, installed and can confirm the issue there too. I usually have a spare basic VM Kubuntu installation and run it in "snapshot" mode, do all the tests and when I turn it off everything is back as previous state, so I can do a "clean" test again at will.
Turns out the lack of functionality here is down to dbus-glib-1 version - which in turn is down to the ancient base-line we're forced to build on, which in turn is related to not having the updated RHEL-5 base to compile from. Caolan - how is that coming along ?
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=535dd86dfa4fbe0f2555205cb925586176267800 fdo#58699 - sdremote - fix it so it closes even with no bluetooth. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Marco - the fundamental problem is a difference in build of the same source code between the really old systems we make the generic builds on (which are missing a recent dbus and hence bluetooth) and the modern developer systems ~all of us use to compile with. That's the root cause of the issue. We'll be pulling up our base system for 4.0.1 I hope - until then you'll need to use a distribution build of 4.0.0 to use the bluetooth remote.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1ff566f4887ae0ddf99159f8f035e9b91a67643d&h=libreoffice-4-0 fdo#58699 - sdremote - fix it so it closes even with no bluetooth. It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed :-)
(In reply to comment #29) > Marco - the fundamental problem is a difference in build of the same source > code between the really old systems we make the generic builds on (which are > missing a recent dbus and hence bluetooth) and the modern developer systems > ~all of us use to compile with. That's the root cause of the issue. > > We'll be pulling up our base system for 4.0.1 I hope - until then you'll > need to use a distribution build of 4.0.0 to use the bluetooth remote. Yes, this issue sure, but sometime I see developers replying that can't reproduce something and they are using a different OS/version/whatever. I think could be trivial have at least 8-10 VM with the main GNU/Linux distro and desktops (20GB x 10VM = 200GB) with gdb installed and be able to reproduce and catch more useful info than every average "QA tester" like me can provide. I've the feeling that developers (and testers also ;P) would save a lot of time this way, i.e. 30 messages on this single issue is a lot of time wasted, every time everyone here has to refocus on what has been tested, carefully re-read what has been said, guess or ask for further info and so on. This is just a friendly suggestion and my opinion, use or ignore it at your own risk ;P
I can verify it's fixed -> VERIFIED FIXED. Thanks everyone involved.
*** Bug 60736 has been marked as a duplicate of this bug. ***
*** Bug 61265 has been marked as a duplicate of this bug. ***