|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | [RFE] properties for form controls should open on double-click | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base | Reporter: | kelvine <kelvineld> | ||||
| Component: | code | Assignee: | christoph.lukasiak | ||||
| Status: | CLOSED FIXED | QA Contact: | issues@dba <issues> | ||||
| Severity: | Trivial | ||||||
| Priority: | P3 | CC: | issues | ||||
| Version: | OOo 1.1 | ||||||
| Target Milestone: | OOo 2.0 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
|
Description
kelvine
2003-12-12 23:14:53 UTC
Hi Bettina, nice idea. This could be part of the PCD about ease-of-use for forms and controls. Bye Marc This issue is considered within the PCD 20318. *** This issue has been marked as a duplicate of 20318 *** Closed. Issue reopened, was closed by mistake. This issue is not related to PCD 20318. Hello Kelvine, thank you for your list of issues. For this issue ID I take the first enhancement into account, as per ID just one issue is handled. Summary for point 1: Properties of a control should open at double click on a control. Hello Frank, please consider this enhancement for OO.o 2.0. Thank you. Hi, No problems. I will recheck the other two points to see if they haven't been raised and then raise them as enhancement requests if appropriate. The summary of this issue should then be probably be changed as well, but I will leave that decision up to yourselves. Thanks Kelvin change subcomponent to 'none' Okay, adjusted the title. synopsis: doublei-clicking onto a form control, or a multi-selection of form controls, or pressing enter while a form control is selected and the focus is int the document window, should open the property browser for this control/selection. moving out to "Later" due to resource constraints, in agreement with KA. (personally: still trying to do this for 2.0 ...) Created attachment 16969 [details]
preliminary patch
The attached patch implements the desired functionality. drawbacks at the moment: - It's relative to the eforms2 CWS, which is not yet in the master - it requires that MouseButtonDown in the SdrObjEditView is made virtual, which would result in a quite expensive CWS (since a lot of modules would need to be built incompatibly for this) So I will wait until eforms2 is in the master, and then probably create a dedicated low-prio CWS for this RFE. fixed in CWS improveforms reopening for re-assign to QA fs->msc: please verify in CWS improveforms fixed in CWS improveforms clu: doubleclick works fine in cws, return on a selected control not CLU: doubleclick does neither work in calc nor in draw (but in text it works fine) CLU->FS: back to you Ooops, this "properties on enter" feature completely slipped my attention, since it's only mentioned in the description, not in the summary. Thanks for finding :). Attempting to implement it, I discovered that the Enter key is already used: When pressed while a grid control is selected, then this control is "focussed", to allow designing it via the keyboard only (this is an accessibility feature). I'll implement the properties upon "Alt-Enter". This is consistent with a) Windows, where Alt-Enter usually indicates "show me the properties of the selection", and b) some other places in OOo (at least the form naviagtor), where this shortcut is also used for this functionality. Added Alt-Enter support reopening for re-assign to QA fs->clu: please verify in CWS improveforms fixed in CWS improveforms verified in cws: works in text and database form (for this two cases it was designed) does not work for the other application (calc,draw ..) - but this is rather unimportant and more a nice to have implementation in the other appclication will follow in future time (as i agreed with FS and MSC) Hi, I've been watching this issue and two things stand out. 1. The issue was about double clicking and not about the use of the ENTER key, whcih and has been added. Should this not have been raised as a separate issue. 2. I'm not certain why double clicking on a form control in Calc, Draw, Impress can't work the same. Not having things work the same introduces inconsistency for users and IMHO this is never good. With further testing I now see that if I double click or press ENTER whilst a shape has focus in Draw, the toolbar changes and the user is put into text entry mode. I never noticed this before. Perhaps this may have guided how doubling clicking was implemented. Given that form controls behave differently to shapes these should be treated differently with regards to the use of ENTER. 3. Using ENTER in one case and ALT-ENTER at another time IMHO introduces inconsistency into the product and again I don't think this is a good design idea. I just thought I would offer my feedback. Thanks Kelvin > 1. The issue was about double clicking and not about the use of the ENTER key, > which and has been added. Should this not have been raised as a separate issue. It could have been, I don't see any good points pro or con it. I just added it because it somehow fits into the topic ... > 2. I'm not certain why double clicking on a form control in Calc, Draw, > Impress can't work the same. Not having things work the same introduces > inconsistency for users and IMHO this is never good. I agree in general. However, let me state that adding the same for Calc/Draw/Impress would have definately moved this issue to "OOo Later": The bug already had this target in the past (rightfully so in the current course towards 2.0, since it's a minor issue), and I decided to add the fix for Writer, which is relatively easy to get. I could not argue the effort for doing all the necessary things for the other apps. Given the forms are mainly used in Writer, while they have nearly no use in Impress/Draw, and relatively small use in Calc, I consider this a good compromise. > With further testing I now see that if I double click or press ENTER whilst a > shape has focus in Draw, the toolbar changes and the user is put into text > entry mode. I never noticed this before. For a single control? I can reproduce this for a combination of, say, a rectangular shape and a control (also in 1.1.x), but not for a single control. In any way, since I doubt that you already have a m54 (which is were this issue is fixed), I suppose this is a separate problem (worth filing, though). > 3. Using ENTER in one case and ALT-ENTER at another time IMHO introduces > inconsistency into the product and again I don't think this is a good design > idea. Where's the inconsistency? I am not aware of a place where ENTER alone opens a properties dialog, but there are several places where ALT-ENTER does. Sorry, I don't get your point here. clu->kelvine,fs: addition to point 1: the rule one bug one issue makes big sense for bugs but rather less sense for new features or enhancements - in this case rather the summary should be more general or include both cases Hi, I'm not really fussed at all. Just trying to do the best by the project by understanding what makes things easy for you guys. This was as per bh's comments on Jan 30, 6:28 in this issue. I'm just following what I've been told on multiple occassions. I think I misread the issue with regards to Enter and Alt-Enter (point 3). Sorry. I've reread things and correct me if I'm wrong, but Alt-Enter alone is being used. Enter is not being used at all. Thanks Kelvin >I'm not really fussed at all. Just trying to do the best by the project by >understanding what makes things easy for you guys. sometimes it differs ;) >This was as per bh's comments on Jan 30, 6:28 in this issue. I'm just >following what I've been told on multiple occassions. in this case it depends on the private definition and there is no clearly right or wrong - bh do not want a collection of different tasks in her issues (this make sense), but if tasks ar so close together like in this case you can speak about one enhancement containing two points (make sense, too - in extreme you could have an enhancement in 25 issues, what would definetly confuse) ... endless discussion >I think I misread the issue with regards to Enter and Alt-Enter (point 3). >Sorry. >I've reread things and correct me if I'm wrong, but Alt-Enter alone is being >used. Enter is not being used at all. right: alt-enter is more common in oo and will be used (enter is used in other cases and would create inconsistences and rework in other places) verified in master (680m54-5) clu->kelvine: you can check it here: http://download.openoffice.org/680/index.html Hi, I tested the double click on a control (using OOm54) and it opens the controls properties as desired. Alt+ENTER also works. It does not work for Calc as stated in this issue for later action. (Obviously also not for Impress and Draw, but I have not tested this.) Just a bit of feedback. I tried to quickly set up a form in a Writer document using a Wizard. I had forgotten this had been gutted from the interface. Doing this from the new Base application doesn't really show me as a user it is working in Writer and Calc. I then resorted to manually creating a form in a Writer document and Calc for testing. I think the new Base document should have been in addition to the existing facilities in OO1.1.x and not an "instead of" approach that has been taken. The learning curve will now be enormous for users. I think the project has made a big mistake in gutting all the functionality from the UI that previously existed. It has certainly made the product less appealing in this area for me. I am also a bit disappointed the double click was not implemented across the entire suite. This has now created an inconsistency in the product which will just confuse users. Personally I would have preferred the change not to have been done at all, rather than introduce another inconsistency. Thanks for your time for performing the change. Kelvin |