Created attachment 118721 [details]
image comparing 2 slides in Impress. First slide (current version of Impress) has no selection outline for the active text box, and second one has an outline (suggested change)
I am currently using Libre Office 22.214.171.124 on Windows 8, 64 bit, Locale en_US
In Impress, it would be convenient if the selection outline box of the text box is made visible when the text box is active (even if its borders are absent). This allows easy scaling/moving of the text box when it is active, without having to search for the selection box every time when it has no borders. Currently, MS Powerpoint follows this and I find it very convenient.
I attached an image showing how a textbox currently looks on selection (top) and how I think it would be more convenient according to my suggestion (bottom).
I am filing this following a suggestion on the Ask Libre Office forums (https://ask.libreoffice.org/en/question/14015/how-to-show-text-box-outline/ )
The selection outline box is showing for me even in 126.96.36.199 when I am typing into a text box.
How have you made it so it is invisible? Maybe we will find out, if you attach a file with the problem?
Win 7 Pro 64-bit, Version: 188.8.131.52 (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)
Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
I came across this bug report when I thought I had the same issue. But after more trials, I find that the actual problem is the textbox is somewhat difficult to select, not that it is not selectable. By difficult, I mean I, as a new user, cannot always select the textbox I want by clicking around the text, and I often need to click multiple times to get it selected. Maybe I (and possibly the bug reporter) did not get the right way to do it?
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INVALID
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Sun, 11 Sep 2016 21:43:24 +0200
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker
I see the same problem what other people have discovered.
"How have you made it so it is invisible? Maybe we will find out, if you attach a file with the problem?"
It doesn't make ANY sense to ask for any file. The problem is in program not in the file. As simple as fact any empty file has it.
I see the bug under Linux with Openoffice 4.1.3 or any new version of Libreoffice.
If I type inside of text box the box borders remain invisible.
To be able to select it one need to click slightly above the text, but then
I can only see cyan rectangles. That is very inconvenient.
Previous versions (3.X) of OpenOffice were working fine. Not it's not.
Openoffice as well as Libreoffice are way too bugy. To find a bug one need sometimes less than 5 min. Why nobody test them?
Well Openoffice is slightly better.
(In reply to Gospodin Baron from comment #5)
> It doesn't make ANY sense to ask for any file. The problem is in program not
> in the file. As simple as fact any empty file has it.
Then why do I not see the problem? It is completely normal to ask for a file in this case.
Do you see the problem in 5.3, if you restart in Safe Mode: https://wiki.documentfoundation.org/UserProfile#Resolving_corruption
Created attachment 132314 [details]
example of ppt document without text borders displayed
As request test file is provided
(In reply to Gospodin Baron from comment #7)
> Created attachment 132314 [details]
> example of ppt document without text borders displayed
> As request test file is provided
With this file I confirm the missing borders. Now do you believe the request made sense?
The bug is already in 4.3.
4.1.6 displays the resizing handles, but not the border.
Maybe an initial bibisecting of the disappearance of handles could be valuable.
Saving as pptx still preserves the problem.
Newest version bug is confirmed in:
Win 7 Pro 64-bit Version: 184.108.40.206.alpha0+ (x64)
Build ID: 74917d23782413aa0f129bcf9e6bf5a1c496d23b
CPU threads: 4; OS: Windows 6.1; UI render: default;
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-04-02_23:58:52
Locale: fi-FI (fi_FI); Calc: CL
Regression introduced by:
author Armin Le Grand <email@example.com> 2013-08-29 16:32:05 (GMT)
committer Caolán McNamara <firstname.lastname@example.org> 2013-08-29 19:02:59 (GMT)
commit b1a6dbc2dd118627360282dd304e24263c3bca51 (patch)
parent e57a73cc6bedcb8f176e1804792a7ea1fd88796b (diff)
Resolves: #i123003# Corrected Handle/Overlay visualization...
when TextEdit is active
Bisected with bibisect-42max.
Adding Cc: to Armin Le Grand
> With this file I confirm the missing borders. Now do you believe the request
> made sense?
Not really. I just need to install the OO/LO to see the bug.
The ppt files aren't coming from Mars. And I don't have a very special & different tool to make them either. If I would, I won't care much about OO/LO and its bugs. Am I right? At least hopefully you can get my point
I am also upset, because developers do not accept the bug just because they can't see them. It reduces the motivation of users to file the bug. Trust me nobody want to spent his time doing so. And if people do that it should be appreciated and not ignored. Especially if we talk about OO/LO! That suite has the highest bugs ranking among all programs I've seen before.
It seems like developers never ever test or even start OO/LO before release.
Personally I just filed the bug, because even in OO 4.1.3 which I have to use under Linux I can see it. I can't find OO 3.X anymore and downgrade further.
No wonder, that city of Munich is going back to MS products.
With introduction of last LO versions you are running against the wall.
Instead of playing with broken features around design you better fix the program. Even DPI font scale is broken at LO and still works fine with OO 4.1.3
Herr Baron, if you like OO more, by all means use it then. We won't mind.
(In reply to Tor Lillqvist from comment #11)
> Herr Baron, if you like OO more, by all means use it then. We won't mind.
You can always stick your head in the sand. Whether it's a good tactic is a different question.
I am just saying, that it's sad, that since so many years starting with StarOffice that suite has never got a broad distribution among people.
Just compare what WPS guys have achieved within much smaller time frame.
Frankly MSO is not perfect (actually far from it), but the fact is, that nobody came even closer to them with all the efforts made. If that would be a commercial organization they would drop the project long ago.
The only solution I see is starting from scratch. Make it clean, compact, plugin based set of programs. Not that super monster we have now. Period.
Created attachment 138078 [details]
Native format (ODP) with missing border around text box.
I confirm this bug in LibreOffice: 220.127.116.11
Build ID: 18.104.22.168-1.fc27
I see the issue in a presentation in .odp format (see attachment). I consider this as a high priority issue as it severely slows down creating presentations for me. I suggest to rise the priority.
Note that I copied the slide in from an other presentation that might have Powerpoint remainders.
Created attachment 138079 [details]
Clean native format (ODP) with missing border around text box.
I did some more testing. I created a clean new Impress presentation, without using a template. The issue is there (see slide 2 of the attachment). So for me this issue is completely unrelated to the PPT file format.
With last document, 2nd page border is not shown inEditMode. It is shown on selection (tab after changing page) and after ending TextEdit (esc).
Not on 1st page. Can be recreated with new Impress doc and two pages - due to 2nd page using Layout 'Title, content'. Seems to be related to that last ObjectType. Creating an empty page (no layout) and/or adding a TextBox that is not connected to PresObj in BG does not show the problem.
High/major should be a more appropriate prioritization considering it's a regression, and we can't really expect users to fish around for the textbox borders.
Bug not reproducible in version
Version: 22.214.171.124.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
(In reply to jenny from comment #17)
> Bug not reproducible in version
> Version: 126.96.36.199.alpha0+ (x64)
> Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
> CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win;
> TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
> Locale: zh-TW (zh_TW); UI-Language: en-US
> Calc: threaded
This is false. It is still reproducible/confirmable.
Arch Linux 64-bit
Build ID: 9059457a1a8385cb80b5dd2c797cee77af4222a9
CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5;
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Built on 30 November 2018