Bug 123577 - Problem creating new label objects
Summary: Problem creating new label objects
Status: RESOLVED FIXED
Alias: None
Product: kst
Classification: Applications
Component: general (show other bugs)
Version: 1.x
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-13 23:10 UTC by Andrew Walker
Modified: 2006-03-20 02:54 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proposed patch (1.90 KB, patch)
2006-03-14 23:17 UTC, Andrew Walker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Walker 2006-03-13 23:10:19 UTC
Version:           HEAD (using KDE KDE 3.5.0)
Installed from:    Compiled From Sources
OS:                Linux

STEPS TO REPRODUCE:

Start Kst
Create a new label, by clicking and dragging, within the default window
Enter some text in the Edit Label dialog that is automatically displayed
Hit Apply

RESULTS:

No change

EXPECTED RESULTS:

The change to the label text is reflected in the window
Comment 1 George Staikos 2006-03-14 18:53:26 UTC
Cannot reproduce this.
Comment 2 Andrew Walker 2006-03-14 19:10:13 UTC
Also a problem with the picture object
Comment 3 Andrew Walker 2006-03-14 23:17:39 UTC
Created attachment 15119 [details]
Proposed patch

Makes behaviour of label and picture more consistent with other view objects.
The view objects are displayed immediately. Hitting Apply when the dialog is
first shown after the object creation has a visible effect.
Comment 4 George Staikos 2006-03-14 23:34:14 UTC
If I'm not mistaken, that backs out:

------------------------------------------------------------------------
r490161 | staikos | 2005-12-20 18:30:23 -0500 (Tue, 20 Dec 2005) | 6 lines

only act as a new dialog if it really is a new dialog.  new variable created
to indicate that this is a 'new' object
backs out some of 490135 to keep legends consistent with labels, since it's
really the same bug.
BUG: 118755



Maybe I misunderstood what the bug is that you're reporting.  Are you saying 
that the problem is that the object does not appear until clicking Apply?  If 
so, the fix should be, in "New" mode, to disable Apply since Apply can't 
"apply" to something that doesn't exist yet.
Comment 5 Andrew Walker 2006-03-14 23:50:56 UTC
The problem is that clicking Apply has no effect because the object is not visible. The object should be visible when the dialog is launched.
Comment 6 Andrew Walker 2006-03-15 00:03:53 UTC
While the proposed patch may (I haven't investigated) conflict with some changes you made for BUG:118755 it in no way conflicts with the original bug - which had to do with an entirely different issue. 
Comment 7 George Staikos 2006-03-15 00:11:21 UTC
   I don't think that we should be creating objects at this stage.  They're 
not finalized, and creating them is simply a hack around the fact that Apply 
doesn't really make sense yet.
Comment 8 George Staikos 2006-03-15 00:23:02 UTC
As far as I can see, this is all that's needed:

Index: ksteditviewobjectdialog_i.cpp
===================================================================
--- ksteditviewobjectdialog_i.cpp       (revision 518714)
+++ ksteditviewobjectdialog_i.cpp       (working copy)
@@ -63,6 +63,7 @@

 void KstEditViewObjectDialogI::setNew() {
   _isNew = true;
+  _apply->setEnabled(false);
 }


(or _apply->hide() if you prefer)
Comment 9 Andrew Walker 2006-03-15 00:28:40 UTC
That is an option, but the wrong one I think.
Comment 10 George Staikos 2006-03-20 02:54:24 UTC
SVN commit 520475 by staikos:

In any case, Apply should be disabled for a new object.  It's only for object
edits.  Basically invalidates this bug report.
BUG: 123577



 M  +1 -0      ksteditviewobjectdialog_i.cpp  


--- trunk/extragear/graphics/kst/src/libkstapp/ksteditviewobjectdialog_i.cpp #520474:520475
@@ -63,6 +63,7 @@
 
 void KstEditViewObjectDialogI::setNew() {
   _isNew = true;
+  _apply->setEnabled(false);
 }