[bug #13873] TextViewInspector: textColor not saved
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13873 Summary: TextViewInspector: textColor not saved Project: GNUstep Submitted by: Fabien_ Submitted on: Thu 07/21/2005 at 10:19 Category: Gorm Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: 1) New Applciation 2) Add a TextView 3) Change the TextColor 4) Save the document 5) quit the document 6) Open The document again 7) select the textView 8) The textView textColor is black ( default ) The strange thing is that ok: in GormTextViewAttributesInspector is called with sender textColor when the document is closed ( that odd ) TODO : check other Inspectors too ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13873 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #13872] Services/window Menu switch to Normal menu unexpectedly
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13872 Summary: Services/window Menu switch to Normal menu unexpectedly Project: GNUstep Submitted by: Fabien_ Submitted on: Thu 07/21/2005 at 10:14 Category: Gorm Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: 1) New Application 2) Add a service Menu 3) Add a Windows Menu 4) Add a submenu 5) select the submenu ( 4) 5) clic on Normal 6) The Services Windows Menu are now set to Normal = bug ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
Re: [patch #3946] Add make support for windows PE resources
So my current inclination (totally open to discussion) is: xxx_WINDOWS_RC_FILES for the files, WINDRES_FLAGS for the flags to pass to the 'windres' program Sounds reasonable ? Any comments ? Sounds perfectly reasonable. Perhaps shorten it to _WIN_RC? The only issue with this solution is that the FLAGS variable is named rather differently to the others. As long as the docs are clear I don't see any problem. I have, btw, some -make docs to contribute too. Good points! ... what about xxx_WINDOWS_RC_FILES and WINDOWS_RC_FLAGS ? not _FLAGS, because rc files aren't flags. Thanks for your opinion ... what's your preference for the flags variable name then ? ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #13872] Services/window Menu switch to Normal menu unexpectedly
Update of bug #13872 (project gnustep): Status:None = Fixed ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
Re: NSAttributedString in table data cells
Quoting Fred Kiefer [EMAIL PROTECTED]: Hi Saso, Sa#65533;o Kiselkov wrote: I found that when my code returns an NSAttributedString as the value for a table data cell it doesn't display it as an attributed string, but instead by sending it description (which obviously isn't right, is it?). The problem is in the code of NSCell's -setObjectValue: which doesn't know about attributed strings. I'd recommend adding a test case there which, if passed an NSAttributedString, invokes [self setAttributedStringValue: object];. is this the behaviour on Cocoa? The change you suggest seems sensible to me (and rather simple to implement), but I would like to be sure we do the same as Apple here. Fred Even if it didn't exist in Cocoa, it isn't an incompatible change where we would solve a particular problem in an incompatible way - we'd simply extend the basic concept to be more intelligent and behave more as people would expect it - to be able to use attributed and nonattributed strings interchangeably in controls. The only difference for an app programmer would be: this one's a plain string and this one's a fancy string. I've attached a patch to NSCell.m (diff'ed against the latest CVS version) which should do it. Regards Saso NSCell.patch Description: Binary data ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
Re: [patch #3946] Add make support for windows PE resources
Nicola Pero wrote: So my current inclination (totally open to discussion) is: xxx_WINDOWS_RC_FILES for the files, WINDRES_FLAGS for the flags to pass to the 'windres' program Sounds reasonable ? Any comments ? Sounds perfectly reasonable. Perhaps shorten it to _WIN_RC? The only issue with this solution is that the FLAGS variable is named rather differently to the others. As long as the docs are clear I don't see any problem. I have, btw, some -make docs to contribute too. Good points! ... what about xxx_WINDOWS_RC_FILES and WINDOWS_RC_FLAGS ? not _FLAGS, because rc files aren't flags. Thanks for your opinion ... what's your preference for the flags variable name then ? I am somewhat indifferent... I'd say xxx_WINDOWS_RC_FILES is best, since the FSF shuns use of WIN to denote Windows. It's less descriptive/clear anyways. ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
Re: [patch #3946] Add make support for windows PE resources
So my current inclination (totally open to discussion) is: xxx_WINDOWS_RC_FILES for the files, WINDRES_FLAGS for the flags to pass to the 'windres' program Sounds reasonable ? Any comments ? Sounds perfectly reasonable. Perhaps shorten it to _WIN_RC? The only issue with this solution is that the FLAGS variable is named rather differently to the others. As long as the docs are clear I don't see any problem. I have, btw, some -make docs to contribute too. Good points! ... what about xxx_WINDOWS_RC_FILES and WINDOWS_RC_FLAGS ? not _FLAGS, because rc files aren't flags. Thanks for your opinion ... what's your preference for the flags variable name then ? I am somewhat indifferent... I'd say xxx_WINDOWS_RC_FILES is best, since the FSF shuns use of WIN to denote Windows. It's less descriptive/clear anyways. Thanks ... I see your point - good point! - I agree WINDOWS is best to denote Windows. :-) So we agree xxx_WINDOWS_RC_FILES is a good choice for the list of files -- good. Now we need two variable names - one for the list of files, one for the flags used to compile the files. Usually in gnustep-make they are named the same (or very similarly), as in OBJC FILES and OBJC FLAGS. But not always exactly the same, for example we have JAVA FILES but JAVAC FLAGS and JAVAH FLAGS. If we agree the variable name for the files is called xxx_WINDOWS_RC_FILES, then I was going to use xxx_WINDOWS_RC_FLAGS for the flags variable, to have a similar/consistent name. Mainly so that someone who doesn't really know anything about this should be able to understand at a quick glance (when looking at a GNUmakefile) that the xxx_WINDOWS_RC_FLAGS variable is related to the xxx_WINDOWS_RC_FILES. Sounds OK ? Thanks ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
Re: NSAttributedString in table data cells
Sašo Kiselkov wrote: Quoting Fred Kiefer [EMAIL PROTECTED]: Sa#65533;o Kiselkov wrote: I found that when my code returns an NSAttributedString as the value for a table data cell it doesn't display it as an attributed string, but instead by sending it description (which obviously isn't right, is it?). The problem is in the code of NSCell's -setObjectValue: which doesn't know about attributed strings. I'd recommend adding a test case there which, if passed an NSAttributedString, invokes [self setAttributedStringValue: object];. is this the behaviour on Cocoa? The change you suggest seems sensible to me (and rather simple to implement), but I would like to be sure we do the same as Apple here. Even if it didn't exist in Cocoa, it isn't an incompatible change where we would solve a particular problem in an incompatible way - we'd simply extend the basic concept to be more intelligent and behave more as people would expect it - to be able to use attributed and nonattributed strings interchangeably in controls. The only difference for an app programmer would be: this one's a plain string and this one's a fancy string. Not sure, if I agree to that. The new behaviour may seem sensible to you and me, but others may rely on the Cocoa behaviour. As soon as I can get hold of Mac, I will try to found out, how it behaves here. Fred ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #13872] Services/window Menu switch to Normal menu unexpectedly
Follow-up Comment #1, bug #13872 (project gnustep): Confirmed. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #13872] Services/window Menu switch to Normal menu unexpectedly
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13872 Summary: Services/window Menu switch to Normal menu unexpectedly Project: GNUstep Submitted by: Fabien_ Submitted on: Thu 07/21/2005 at 10:14 Category: Gorm Severity: 3 - Normal Item Group: Bug Status: Fixed Privacy: Public Assigned to: gcasa Open/Closed: Open ___ Details: 1) New Application 2) Add a service Menu 3) Add a Windows Menu 4) Add a submenu 5) select the submenu ( 4) 5) clic on Normal 6) The Services Windows Menu are now set to Normal = bug ___ Follow-up Comments: --- Date: Fri 07/22/2005 at 01:38 By: Gregory John Casamento gcasa Confirmed. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
Re: NSAttributedString in table data cells
--- Fred Kiefer [EMAIL PROTECTED] wrote:
Sao Kiselkov wrote:
Quoting Fred Kiefer [EMAIL PROTECTED]:
Sa?o Kiselkov wrote:
I found that when my code returns an
NSAttributedString as the value for a
table
data cell it doesn't display it as an attributed
string, but instead by
sending
it description (which obviously isn't right, is
it?). The problem is in
the
code of NSCell's -setObjectValue: which doesn't
know about attributed
strings. I'd recommend adding a test case there
which, if passed an
NSAttributedString, invokes [self
setAttributedStringValue: object];.
is this the behaviour on Cocoa? The change you
suggest seems sensible to
me (and rather simple to implement), but I would
like to be sure we do
the same as Apple here.
Even if it didn't exist in Cocoa, it isn't an
incompatible change where we would
solve a particular problem in an incompatible way
- we'd simply extend the basic
concept to be more intelligent and behave more as
people would expect it - to be
able to use attributed and nonattributed strings
interchangeably in controls.
The only difference for an app programmer would
be: this one's a plain string
and this one's a fancy string.
Not sure, if I agree to that. The new behaviour may
seem sensible to you
and me, but others may rely on the Cocoa behaviour.
As soon as I can get
hold of Mac, I will try to found out, how it behaves
here.
i believe this has been discussed multiple times in
the past..
GNUstep complies with the documented behaviour
it seems that while mac osx may comply with the
documented behaviour, it has some sort of magic
default formatters to format everything (i don't quite
understand this since formatters work with strings and
not objects)... anyhow IMHO the documentation of the
implementation isn't as important what the developer
can expect to happen/be returned when calling a
method, and in that regard their documentation *was*
broken last time i looked at it at least.
i can't actually figure out how to make
-hasValidObjectValue return NO on a mac :)
so this issue doesn't seem to be limited to attributed
strings...
attached test program, and below is output...
matt
(make -f Makefile on a mac)
GNUstep:
2005-07-21 18:37:02.000 cellTest[11056]
-objectValue=(nil) KindOf=(nil) formatter=(nil)
hasValidObjectValue=NO
2005-07-21 18:37:02.000 cellTest[11056] NSAnyType
2005-07-21 18:37:02.000 cellTest[11056]
-objectValue=(nil) KindOf=(nil) formatter=(nil)
hasValidObjectValue=NO
2005-07-21 18:37:02.000 cellTest[11056] NSAnyType
2005-07-21 18:37:02.000 cellTest[11056]
-objectValue=(nil) KindOf=(nil) formatter=(nil)
hasValidObjectValue=NO
2005-07-21 18:37:02.000 cellTest[11056] NSAnyType
2005-07-21 18:37:02.000 cellTest[11056] 23 23.50
23.50
2005-07-21 18:37:02.000 cellTest[11056]
-objectValue=(nil) KindOf=(nil) formatter=(nil)
hasValidObjectValue=NO
2005-07-21 18:37:02.000 cellTest[11056] NSAnyType
2005-07-21 18:37:02.000 cellTest[11056]
-objectValue=(nil) KindOf=(nil) formatter=(nil)
hasValidObjectValue=NO
2005-07-21 18:37:02.000 cellTest[11056] NSAnyType
Mac:
2005-07-21 18:21:35.390 cellTest[4791] -objectValue=55
KindOf=NSCFNumber formatter=(null)
hasValidObjectValue=YES
2005-07-21 18:21:35.391 cellTest[4791] NSAnyType
2005-07-21 18:21:35.392 cellTest[4791]
-objectValue=Foo: 0x527160 KindOf=Foo
formatter=(null) hasValidObjectValue=YES
2005-07-21 18:21:35.393 cellTest[4791] NSAnyType
2005-07-21 18:21:35.394 cellTest[4791]
-objectValue=23.5 KindOf=NSCFNumber formatter=(null)
hasValidObjectValue=YES
2005-07-21 18:21:35.395 cellTest[4791] NSAnyType
2005-07-21 18:21:35.396 cellTest[4791] 23 23.50
23.50
2005-07-21 18:21:35.398 cellTest[4791]
-objectValue=zxcv{} KindOf=NSConcreteAttributedString
formatter=(null) hasValidObjectValue=YES
2005-07-21 18:21:35.399 cellTest[4791] NSAnyType
2005-07-21 18:21:35.400 cellTest[4791]
-objectValue=(null) KindOf=(null) formatter=(null) hasValidObjectValue=YES
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
cellTest.tar.gz
Description: 2877085026-cellTest.tar.gz
___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #13873] Text color not saved in NSTextView
Update of bug #13873 (project gnustep): Category:Gorm = Gui/AppKit Summary: TextViewInspector: textColor not saved = Text color not saved in NSTextView ___ Follow-up Comment #1: This can be tested in Gorm, using the instructions above, but it is not a Gorm issue. It seems that in encodeWithCoder: text color is not saved. GJC ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13873 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
