Version: (using KDE KDE 3.2.0) Installed from: Compiled From Sources Compiler: GCC-3.3.2 OS: Linux The following group of editing actions in Quanta are not properly enabled/disabled: Undo Redo Cut Copy Paste Current behaviour (3.2-RC1): - They are always enabled when source editor is active, even just after opening a new document and before modifying it. - They are *never* enabled when VPL editor is active, even after modifying the document. The correct behavior is for both editors: - Disabled (greyed out) until the file is changed - Enabled after the file is changed (for all the session, including after 'save' actions) This *should* be fixed for 3.2, as it is *very* confusing. To illustrate this, do the following: 1. Open a document 2. Activate Source Editor, check that these actions are enabled. 3. Activate VPL, check that these are disabled 4. Modify the file 5. Check that actions are still disabled in source editor
The severity is set by using the severity combobox and not by adding "(grave)" to the summary.
Subject: Re: New: Editing actions not correctly enabled and differ between VPL and Source Editors (grave) Hi, In VPL mode, the Undo/Redo/Copy/Paste is not yet implemented, this was the cause why they were disabled. In text mode we don't care right now, and they are enabled always (and usable). The current solution is enabling the actions also in VPL and giving an error message if you try to use them. Of course we will implement the missing functionality ASAP. Does this behavior satisfy you currently? If so, I propose changing the report to a wishlist. Andras
Hi Andras, I found some other facts with regards to document history, see below. I do think this is a bug, and a serious one from the usability point of view. It is not a 'not-implemented-yet' feature, but rather a 'not-working-as-it-should' behaviour. Users look at menus the following way: - Undo/Redo disabled => there is no history (nothing to undo) - Undo/Redo enabled => history present (the document is modified) with the obvious consequences on the need to worry about saving the document: - nothing to undo => no need to save - modified => I have to save at some point, or I will lose my changes Nothing new so far. 1. One problem in VPL _never_ showing Undo/Redo enabled, and Source Editor _always_ showing it is that those users expectations are violated: - In VPL mode, the user always feels (wrongly) that there is nothing to save, and if he knows he just modified the document and sees no Undo/Redo, he thinks that history (accumulating user actions) is not working (which is wrong too, see below). - In Source Editor, the user feels that the document has unsaved changes, even if he just opened it. This is a minor annoyance though. 2. Another *worse* (IMHO) problem is that the history actually works (and correctly) across both modes: user modifications are accumulated in the order they are performed, regardless of the mode of the editor To illustrate this point, do the following: - Open a document - Activate the VPL editor. (Undo disabled) - Modify the document (Undo still disabled) - Activate the Source Editor to enable Undo in the GUI - Perform Undo - Activate VPL editor => VPL-mode changes are undone! A user wanting top use the VPL editor and history will constantly have too juggle between editors just to enable undo/redo. As far a satisfying me, no worry there: I *LOVE* Quanta and can easily live with this feature since I know how to deal with it, but I think a lot of users will be very confused indeed. PS: For Stephan: I used the the 'Report a new wish, bug or crash' action from http://bugs.kde.org main page, which enables me to select among wish, bug or crash (not surpisingly) but not any other severity. So I put grave in the title, which had the expected effect to attract attention from bugs maintainers, but not quite the desired one to be bumped to grave status ;-)
Ok so 1) doesn't apply anymore, instead a message box is poping up when called from VPL saying that it is not implemented. Concerning 2), in fact, kate store the update of the Html source from VPL. I can't do anything (i can't stop kate to keep in history the updates of the source from VPL). Besides, the synchronization of kate can be triggered every <insert a big number here> ms, and thus a undo can bring us far back! But even if we could avoid kate to store the changes when we are in VPL, it wouldn't be a good idea : we woudn't be able to undo! But i will work on a common undo/redo system (well already started, but i lack of time :(
Undo/Redo and Copy/Paste is implement for VPL in CVS HEAD. It might have some bugs, but the functionality is there.