Ok, I'll make the changes to the classes.
I will have revised GUI help and be finished with the intro by the end
of the weekend. I'll try to figure out how many examples have the gui
syntax. Do we really need to get rid of all of them? We're not
deprecating it, are we?
The gui intro will use only the new syntax, but will mention the old
one.
The table of gui classes will be moved to a GUI Classes help file, and
will include all syntaxes.
jostm
Scott Wilson wrote:
Okay.
Another thing that needs to be done is to replace all examples
using the old GUI.widget syntax with the new improved. That could
probably be done search and replace with script, I think.
S.
On 11 Dec 2008, at 22:02, jostM wrote:
Now that we have the stubs,
I actually don't think they are all that annoying, especially since you
can simply click on a link to continue. Cmd-y on the other hand is
utterly absurd:
Cmd-y on Slider.
Cmd-y on the key, \slider.
Cmd-y on Meta_CocoaGUI:slider
Cmd-Y on SCSlider
finally you're there
brrrrr
jostM
Scott Wilson wrote:
I
guess so, if people are in agreement with this.
Regarding having the notion of having the help for the
redirect classes forward on to the implementation doc:
I've been mulling this over, and to make it work with the
search we would need to either hard code it in Cocoa, or move the help
process through SCLang. Neither solution is really simple though, since
help searching/opening is done differently in different
platforms/editors.
Maybe a better solution would be something like the way
quarks work. So you could have a directory with the stub files, and
then just swap in a directory of files with the same names, with just a
little html to forward to the desired files, or possibly links (maybe a
windows issue there...). I think that should work, but would be
worth testing. This might be more easily cross-platform, and simpler to
implement completely in the lang.
You could configure it with something like
Help.forwardGUIStubs = true;
S.
On 11 Dec 2008, at 17:27, jostM wrote:
So I take it that means we can change the names and
redirect all of the
classes in the list I made, except Font?
Or are there any other concerns pending?
I did try it already, an only Font was making a problem. On the whole, I
don't see too many reasons why the class identity of the rest on the
list is likely to be important in anyone's code.
jostM
Scott Wilson wrote:
I think that makes sense actually.
S.
On 11 Dec 2008, at 15:51, Julian
Rohrhuber wrote:
I wonder whether Font is not a more
neutral class anyway, a bit more
like FlowLayout etc. It is just these
methods, that could maybe be
moved/redirected to the GUI class,
and then to Platform.
*availableFonts {
// returns an Array of font
names.
_Font_AvailableFonts
^this.primitiveFailed
}
*antiAliasing_ { arg flag = false;
_Font_SetAntiAliasing;
^this.primitiveFailed
}
*smoothing_ { arg flag = false;
_Font_SetSmoothing;
^this.primitiveFailed
}
OK, redirecting Font breaks code.
SCButton wants font_ to have an
argument of type Font. I think this is
checked in the primitive
ERROR: Primitive
'_SCView_SetProperty' failed.
Wrong type.
RECEIVER:
nil
CALL STACK:
MethodError:reportError
16D95F40
arg this = <instance of
PrimitiveFailedError>
Nil:handleError 16D95EE0
arg this = nil
arg error = <instance of
PrimitiveFailedError>
Thread:handleError 16D95760
arg this = <instance of
Thread>
arg error = <instance of
PrimitiveFailedError>
Object:throw 16D95D60
arg this = <instance of
PrimitiveFailedError>
Object:primitiveFailed 16D95D00
arg this = nil
SCButton:font_ 16D95BB0
arg this = <instance of
SCButton>
arg argFont = <instance
of SCFont>
Server:makeGui 15C01290
arg this = <instance of
Server>
arg w = <instance of
SCWindow>
var active = nil
var booter = <instance of
SCButton>
var killer = nil
var makeDefault = nil
var running = nil
var booting = nil
var stopped = nil
var bundling = nil
var recorder = nil
var scoper = nil
var countsViews = nil
var ctlr = nil
var dumping = false
var label = "internal server"
var gui = class CocoaGUI
var font = <instance of
SCFont>
var volumeNum = nil
Server:makeWindow 16D95220
arg this = <instance of
Server>
arg w = nil
OSXPlatform:startup 16D82400
arg this = <instance of
OSXPlatform>
Main:startup 16D823A0
arg this = <instance of
Main>
jostM wrote:
Redirects which require that we
change class names could break code,
e.g. if someone is expecting a
class of name Font, Pen ,
FreqScope, or
Stethoscope to be returned.
last chance to veto these:
Font redirect-> SCFont
Pen redirect-> SCPen
FreqScope redirect->
SCFreqScopeWindow (used to be FreqScope)
Stethoscope redirect->
SCStethoscope
jostM
_______________________________________________
sc-dev mailing list
info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list
info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/
--
.
_______________________________________________
sc-dev mailing list
info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list
info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/
|