David-

Wednesday, July 29, 2009, 8:22:08 AM, you wrote:

> I write the uRip properties in a script Metadata header - on compile this is
> saved as a uRIP - that way I never need to check the custom properties
> because I can see them directly in the script.

Hmmm. That sounds interesting. Can you elaborate on that?

--
-Mark Wieder
  mwieder@...

I write the uRip properties in a script Metadata header - on compile this is
saved as a uRIP - that way I never need to check the custom properties
because I can see them directly in the script.

2009/7/29 Trevor DeVore <lists@...>

> --- In revInterop@yahoogroups.com, Mark Wieder <mwieder@...> wrote:
> >
> > Well, I'm not keen on changing it either, but if we want to encourage
> > people to use the standard then we probably shouldn't have roadblocks
> > like this. I ran across this when I went to update the name of one of
> > my stacks and fell afoul of the the new property editor restriction.
> > Had to pop up the message box and do it the long way around.
>
> I would vote for not changing it. The Rev behavior in the PI is troublesome
> for more than just uRIP settings and needs to be fixed. Also, I think
> getting people to use the standard is more likely if they have a nice plugin
> to view and edit uRIP settings. If you just use the PI you have to go back
> and forth between a document figuring out which properties you are supposed
> to add. This is cumbersome.
>
> Regards,
>
> --
> Trevor DeVore
> Blue Mango Learning Systems
> www.bluemangolearning.com    -    www.screensteps.com
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

--- In revInterop@yahoogroups.com, Mark Wieder <mwieder@...> wrote:
>
> Well, I'm not keen on changing it either, but if we want to encourage
> people to use the standard then we probably shouldn't have roadblocks
> like this. I ran across this when I went to update the name of one of
> my stacks and fell afoul of the the new property editor restriction.
> Had to pop up the message box and do it the long way around.

I would vote for not changing it. The Rev behavior in the PI is troublesome for
more than just uRIP settings and needs to be fixed. Also, I think getting people
to use the standard is more likely if they have a nice plugin to view and edit
uRIP settings. If you just use the PI you have to go back and forth between a
document figuring out which properties you are supposed to add. This is
cumbersome.

Regards,

--
Trevor DeVore
Blue Mango Learning Systems
www.bluemangolearning.com    -    www.screensteps.com

OK - that's 2:1 in favour of change. I'm fine if others want to change this.

2009/7/29 Mark Wieder <mwieder@...>

> David-
>
> Well, I'm not keen on changing it either, but if we want to encourage
> people to use the standard then we probably shouldn't have roadblocks
> like this. I ran across this when I went to update the name of one of
> my stacks and fell afoul of the the new property editor restriction.
> Had to pop up the message box and do it the long way around.
>
> --
> -Mark
>  mwieder@...
>

NB - a couple of questions and thoughts on the following:

    1. What do people name at the moment with uRIP ["name"]? For me it is
    mainly libraries, and widgets/views. Though I have inconsistently named
    other types of structures these are the main ones - so things like tree
    views and libraries.
    2. Why not use behaviors instead of custom properties?

The last suggestion is an early stage thought - based on an issue I've had
integrating standard rev controls into my view/widget architecture. That is
I want a script to be able to tell if a field is a standard rev control or a
field within a view/widget. Now without the feature enhancement of scripts
not having access to the internals widgets I've been doing the following:

    - Each view has uRip ["name"] property based on it's template/library
    view
    - Each view must have the following two handlers "getprop view_Object",
    and "getprop view_Name"

From these it is possible for a script to query a field and see if it is
inside a view, and if so what the name and therefore library object is of
that view. OK - but this is:

    1. A lot of custom properties set and saved with each rev control
    2. Less flexible than using behaviors to define the same things that uRIP
    does. Changeing a "getprop uRip" handler once or a few times is a lot easier
    than finding every custom property ouut there.

Personally i almost never use the property inspector, and prefer to use the
script editor where I can because everything is in one place and visible.
I'd argue that the standard should be dealing with what properties are
defined, and not how they are implemented - so the uRip ["name"] of a
control can be stored any way you want. That said changeing this to uRip
["_name"] or similar is fine with me. Thoughts and feedback appreciated.


[Non-text portions of this message have been removed]

David-

Well, I'm not keen on changing it either, but if we want to encourage
people to use the standard then we probably shouldn't have roadblocks
like this. I ran across this when I went to update the name of one of
my stacks and fell afoul of the the new property editor restriction.
Had to pop up the message box and do it the long way around.

--
-Mark
  mwieder@...

I use uRIP ["name"] pretty extensively by now - not keen on changing it just
to get around RevIDE issues. If we did I guess, I'd go for a
"type-of-component" classification - maybe an mvc type classification "view
name", "model name", and / or things like "library name", "tool name" ??? We
get those with name + type at the moment (I think "type" is part of the
standard unless I added it :)

2009/7/28 Mark Wieder <mwieder@...>

> hi-
>
> Recently the rev IDE's property inspector has gotten a bit
> over-zealous about not allowing keywords as custom property names
> (filed as BZ #8186), even if they're in a custom propertyset. This has
> the effect for us of not allowing the assignment of uRIP["name"]
> through the property inspector, only by a script.
>
> I don't really expect this bug report to be processed, so I'd like to
> suggest that we look at our standard uRIP assignments and think about
> renaming at least the "name" property. I'm using "stackName" in the
> one case that came up for me, since I needed access to a stack name
> property, but obviously that isn't a generic solution. Any thoughts?
>
> --
> -Mark Wieder
>  mwieder@...
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

hi-

Recently the rev IDE's property inspector has gotten a bit
over-zealous about not allowing keywords as custom property names
(filed as BZ #8186), even if they're in a custom propertyset. This has
the effect for us of not allowing the assignment of uRIP["name"]
through the property inspector, only by a script.

I don't really expect this bug report to be processed, so I'd like to
suggest that we look at our standard uRIP assignments and think about
renaming at least the "name" property. I'm using "stackName" in the
one case that came up for me, since I needed access to a stack name
property, but obviously that isn't a generic solution. Any thoughts?

--
-Mark Wieder
  mwieder@...

On Apr 30, 2009, at 12:35 AM, Mark Wieder wrote:

> Tereza-
>
> Wednesday, April 29, 2009, 4:06:46 PM, you wrote:
>
>> Do you think I could make it go with Galaxy, too?
>
> I seriously doubt it. What I had to implement in glx2 (and this goes
> back to the heart of the interoperability matter) is a switch like
> this anytime we want to reference one of the IDE stacks:
>
> function glx2GetIDEStackName pRevIDEStackName
>    local tStackName
.
.
.
>
>    else
>        -- we're not in Kansas any more
>    end if
>    return tStackName
> end glx2GetIDEStackName
>

A shame. Despite the virtues of GLX2, I long for the project editor
(stack/object browser with search) and customized contextual menus of
Galaxy. Compact. Convenient. Fast.

Sigh.

t


--
Tereza Snyder
Califex Software, Inc.
<www.califexsoftware.com>

Similarly I have a number of switches for things like (from memory):

    - ide_ScriptEditor
    - ide_SelectedScriptObject
    - ide_ScriptEditorField

which switch depending on the "ide_Environment", and then

    - rev_ScriptEditor
    - glx_ScriptEditor
    - ...

These allow tools that work on scripts to interoperate with the Script
Editor from either environment. Over the years, the way Galaxy / GLX2 has
defined these has changed. So then we have a versioning problem as well -
putting these all together it becomes seriously hard to distribute tools
that say work with the script currently shown in a script editor.

Dividing up the responsibility a bit, with the IDE manufacturers being
encourage to expose certain properties which as far as possible stay
constant accross versions, would help here.


2009/4/30 Mark Wieder <mwieder@...>

function glx2GetIDEStackName pRevIDEStackName
>    local tStackName
>
>    if "revErrorDisplay" is pRevIDEStackName then
>        put "revGLX2 Execution Error" into tStackName
>    end if
>    if there is a stack pRevIDEStackName then
>        -- we're running with the rev IDE
>        -- just return the rev stack name
>        put pRevIDEStackName into tStackName
>    else if there is a stack "MetaCard Menu Bar" then
>        -- we're running in the MetaCard IDE
>        switch pRevIDEStackName
>            case "revMenubar"
>                put "MetaCard Menu Bar" into tStackName
>                break
>            case "revTools"
>                put "Tools" into tStackName
>                break
>            case "revPreferences"
>                put "Preferences" into tStackName
>                break
>            case "revSearch"
>                put "Find" into tStackName
>                break
>            case "revErrorDisplay"
>                put "Execution Error" into tStackName
>                break
>            default
>        end switch
>    else
>        -- we're not in Kansas any more
>    end if
>    return tStackName
> end glx2GetIDEStackName


[Non-text portions of this message have been removed]

Tereza-

Wednesday, April 29, 2009, 4:06:46 PM, you wrote:

> Do you think I could make it go with Galaxy, too?

I seriously doubt it. What I had to implement in glx2 (and this goes
back to the heart of the interoperability matter) is a switch like
this anytime we want to reference one of the IDE stacks:

function glx2GetIDEStackName pRevIDEStackName
     local tStackName

     if "revErrorDisplay" is pRevIDEStackName then
         put "revGLX2 Execution Error" into tStackName
     end if
     if there is a stack pRevIDEStackName then
         -- we're running with the rev IDE
         -- just return the rev stack name
         put pRevIDEStackName into tStackName
     else if there is a stack "MetaCard Menu Bar" then
         -- we're running in the MetaCard IDE
         switch pRevIDEStackName
             case "revMenubar"
                 put "MetaCard Menu Bar" into tStackName
                 break
             case "revTools"
                 put "Tools" into tStackName
                 break
             case "revPreferences"
                 put "Preferences" into tStackName
                 break
             case "revSearch"
                 put "Find" into tStackName
                 break
             case "revErrorDisplay"
                 put "Execution Error" into tStackName
                 break
             default
         end switch
     else
         -- we're not in Kansas any more
     end if
     return tStackName
end glx2GetIDEStackName

--
-Mark Wieder
  mwieder@...

On Apr 28, 2009, at 11:09 AM, Mark Wieder wrote:

> David-
>
> Monday, April 27, 2009, 5:48:55 AM, you wrote:
>
> Not to sidetrack the issue of an plugin interoperability structure,
> but the latest glx2 beta (both the script editor and debugger) does
> work with MetaCard. Hasn't been announced, but we did a lot of work
> under the hood to enable compatibility. Yes, you still need to get a
> license for it, but if you've got a license to use it with rev you're
> all set. Copy it into your MC plugins folder and you're good to go.

Hooray!

I've been sidetracked for a while into web development with Django and
Python etc. in my day job, but now I get to do a proof-of-concept in
Rev (leading to a web-deployed stack next year I hope) and I had
resolved to go back to MetaCard for my preferred IDE. But...but... I
needed GLX2! And now I've got it!

Hip Hip!

t

Do you think I could make it go with Galaxy, too?



--
Tereza Snyder
Califex Software, Inc.
<www.califexsoftware.com>

> Not to sidetrack the issue of an plugin interoperability structure,
> but the latest glx2 beta (both the script editor and debugger) does
> work with MetaCard. Hasn't been announced, but we did a lot of work
> under the hood to enable compatibility. Yes, you still need to get a
> license for it, but if you've got a license to use it with rev you're
> all set. Copy it into your MC plugins folder and you're good to go.

That's great to hear, Mark!

Ken Ray
Sons of Thunder Software, Inc.
Email: kray@...
Web Site: http://www.sonsothunder.com/

On 12.04.09 at 20:58 -0700 Mark Wieder apparently wrote:
>I'm not sure that "containing" one-or-more stacks would work. Maybe
>relative file paths to the various stacks and documents. The project
>file or object could end up growing hugely otherwise. And relative
>links would make it possible to copy the project directory to another
>environment for work. I'm envisioning:
>
>Project directory
>-- Project file
>-- Source directory
>---- Mainstack
>---- Auxiliary stacks
>-- Documentation
>---- project docs
>---- todo list
>---- bug tracking
>-- Multimedia documents
>-- PDF documents
>-- Unit tests
>-- Archived older versions
>-- etc
>
>I'd like to see version-control links to subversion. Someday.
>And dependencies is the key operative word: the project file or object
>should keep track of file dates and/or sizes so it can determine when
>a project file has changed, and therefore the project is out of date.
>
>--
>-Mark Wieder
>  mwieder@...

Isn't this going into building plist-type structures from OSX?

Robert

David-

Monday, April 27, 2009, 5:48:55 AM, you wrote:

Not to sidetrack the issue of an plugin interoperability structure,
but the latest glx2 beta (both the script editor and debugger) does
work with MetaCard. Hasn't been announced, but we did a lot of work
under the hood to enable compatibility. Yes, you still need to get a
license for it, but if you've got a license to use it with rev you're
all set. Copy it into your MC plugins folder and you're good to go.

--
-Mark Wieder
  mwieder@...

I'd be real interested in starting to use / develop for the MC IDE, but
don't want to have to switch between applications. Here are my thoughts on
some future directions for discussion:

    1. Separate as many as possible MC IDE components out as standalone
    componenets that can be used in any Rev based environment. List those
    components that already can sit happily in other IDE's.
    2. Develop a RevIde API - more than just the plugin API, one in which we
    can easily switch in and out Script Editors, Property Palettes and menus. Do
    this step by step, and encourage some sort of formalisation of this through
    discussions with other IDE providers.
    3. Link the above in with Rev Interop

I've a few hacks - that try to hook my tools into the RevIDE or GLX2 IDE's
script editors, the MC IDE and others on the Rev list have their own Script
Editors, so I thought that might be a good place to start = Script Editor
Switcheroo API. That is a way to switch between different Script Editors,
and to be able to define and add your own alterrnatives. I am not exacly
sure what interop would be required for that - Richard posted a similar
question regarding ROSE a year or so back - maybe some hooks to respond to
the debugger?

What do you think?


[Non-text portions of this message have been removed]

Alain-

Friday, April 10, 2009, 12:55:02 PM, you wrote:

> This may or may not be useful to y'all, but in my opinion a
> PROJECT has a [much] BROADER SCOPE than just a stack. A "project"
> should be a container that contains one-or-more stacks ; as well as
> other files, project manage stuff, etc. Even various versions of the
> "project" in-question, e.g. its entire history, relationships with
> other documents, etc, etc.

Yes! Absolutely.

> It goes without saying that all or any subset of the above would
> not FIT into ONE property! I therefore suggest that a "PROJECT" be
> defined as an object, specifically a container, that contains
> one-or-more stacks +etc.

I'm not sure that "containing" one-or-more stacks would work. Maybe
relative file paths to the various stacks and documents. The project
file or object could end up growing hugely otherwise. And relative
links would make it possible to copy the project directory to another
environment for work. I'm envisioning:

Project directory
-- Project file
-- Source directory
---- Mainstack
---- Auxiliary stacks
-- Documentation
---- project docs
---- todo list
---- bug tracking
-- Multimedia documents
-- PDF documents
-- Unit tests
-- Archived older versions
-- etc

I'd like to see version-control links to subversion. Someday.
And dependencies is the key operative word: the project file or object
should keep track of file dates and/or sizes so it can determine when
a project file has changed, and therefore the project is out of date.

--
-Mark Wieder
  mwieder@...

Richard-

Monday, April 6, 2009, 9:41:29 AM, you wrote:

> 3. Is this actually useful, or could there be some other way of
> dealing with multi-file deployments that may be quite different?

Very useful, but I'm wondering if it might not be possible to
piggyback off the existing cRevStandaloneSettings propertyset of a
stack?

--
-Mark Wieder
  mwieder@...

A simplistic answer might be "the components required to deliver the
outcome". Required hardware (such as external servers and their software,
data routing maps, supporting infrastructure etc) may be also important... A
'project' could frankly include anything and everything, so there has to be
a cut-off point. I would (tentatively) suggest that a 'project manifest'
comprises the stacks, externals and media resources required for the
application to function as expected.

/H


-----Original Message-----
From: revInterop@yahoogroups.com [mailto:revInterop@yahoogroups.com]
Sent: 11 April 2009 11:51
To: revInterop@yahoogroups.com
Subject: [revInterop] Digest Number 100

Hi Richard Gaskin and RevInterop crowd, :)

> If there were a common definition of a "project",
> such tools could be used interchangeably.

Indeed! I wholeheartedly agree. There is strength in unity! :-)

> 1. Should a "project" be defined as a property of the
> mainstack for an app, or should it be a separate file?

This may or may not be useful to y'all, but in my opinion a PROJECT has a
[much] BROADER SCOPE than just a stack. A "project" should be a container
that contains one-or-more stacks ; as well as other files, project manage
stuff, etc. Even various versions of the "project" in-question, e.g. its
entire history, relationships with other documents, etc, etc.

It goes without saying that all or any subset of the above would not FIT
into ONE property! I therefore suggest that a "PROJECT" be defined as an
object, specifically a container, that contains one-or-more stacks +etc.

The fact that a stack belongs to a project could, of course, be encoded as a
property of the stack: e.g. the project of stack myStackRef

> 2. What info should be included
> in the definition for a "project"?

VERY-good question, Richard. :)

> 3. Is this actually useful,
> or could there be some other
> way of dealing with multi-file
> deployments that may be quite
> different?

Good question, Richard. Btw, I applaud your 'scholarly' approach of not
overlooking what may have already been done. Not "re-inventing the wheel" as
it were.

> I'm very interested in your feedback.

I now recede back into the obscurity of mute observation, ;-)

Alain

Hi Richard Gaskin and RevInterop crowd,  :)

> If there were a common definition of a "project",
> such tools could be used interchangeably.

Indeed! I wholeheartedly agree. There is strength in unity!  :-)

> 1. Should a "project" be defined as a property of the
> mainstack for an app, or should it be a separate file?

This may or may not be useful to y'all, but in my opinion a PROJECT has a [much]
BROADER SCOPE than just a stack. A "project" should be a container that contains
one-or-more stacks ; as well as other files, project manage stuff, etc. Even
various versions of the "project" in-question, e.g. its entire history,
relationships with other documents, etc, etc.

It goes without saying that all or any subset of the above would not FIT into
ONE property! I therefore suggest that a "PROJECT" be defined as an object,
specifically a container, that contains one-or-more stacks +etc.

The fact that a stack belongs to a project could, of course, be encoded as a
property of the stack: e.g. the project of stack myStackRef

> 2. What info should be included
> in the definition for a "project"?

VERY-good question, Richard.  :)

> 3. Is this actually useful,
> or could there be some other
> way of dealing with multi-file
> deployments that may be quite
> different?

Good question, Richard. Btw, I applaud your 'scholarly' approach of not
overlooking what may have already been done. Not "re-inventing the wheel" as it
were.

> I'm very interested in your feedback.

I now recede back into the obscurity of mute observation,  ;-)

Alain

2009/4/6 Richard Gaskin <Ambassador@...>

1. Should a "project" be defined as a property of the mainstack for an app,
> or should it be a separate file?


I'd say a property of the stack - as this could also be implemented as a
getprop which reads a manifest (text file).

2. What info should be included in the definition for a "project"?


The main thing I need and have just started working on is dependencies  and
I am not sure if this is related directly to what you mean by project. I
want a script to be able to download resources usually stacks containing
libraries from the internet - allowing you to send out individual stacks -
and not whole environments?


> 3. Is this actually useful, or could there be some other way of dealing
> with multi-file deployments that may be quite different?


What are the use cases you see - I guess I'm looking for more of the sort of
thing you get with project compilers that deal with dependencies - given the
text file (or stack with property) - a tool can download and form a complete
application? I think that would be very useful - though personally I would
want it for every stack and not just the mainstack for the app.


[Non-text portions of this message have been removed]

There is a broad category of tools which could benefit from having some
definition of a "project", a list of all UI stacks, libraries, externals, etc.
that comprise a given product or system.

The types of tools that could use this information include installer makers,
version control systems, code analyzers, and even marketing support.  If there
were a common definition of a "project", such tools could be used
interchangeably.

This raises a variety of questions:

1. Should a "project" be defined as a property of the mainstack for an app, or
should it be a separate file?

2. What info should be included in the definition for a "project"?

3. Is this actually useful, or could there be some other way of dealing with
multi-file deployments that may be quite different?

I'm very interested in your feedback.

Hi, all.  Looking at this thread together with the prior thread, it seems
developers ought to choose what they want from the library, and register for
updates.  A developer could use a shopping cart, a shopping assistant, and a
shopping list.  (Here are the top downloads... Developers that chose this
library also chose that library.)  Are there Rev apps for shopping already?
Or could the community create the functionality for the library, and include
it the library?
Imagine lots more contributors and contributions.  How do the moderators
decide what to accept and reject?
-- Dick


On 9/28/08 2:13 PM, "Thomas McGrath III" <mcgrath3@...> wrote:

>
>
>
> I'm all for two libraries. A Utility library might interest more than
> a few people if it provided enough utilities.
>
> Tom McGrath
>
> On Sep 26, 2008, at 5:01 PM, Robert Brenstein wrote:
>
>> > On 26/09/08 at 14:35 -0500 Chipp Walters apparently wrote:
>>> > >Richard,
>>> > >After you asked that, I got to thinking why would I want this
>> > function in
>>> > >stdLib? And in all the years of using Rev, I have never had the
>> > need to
>>> > >use "isStackCurrentlyVisibleOnAnyMonitor."
>>> > >
>>> > >So, I'm not sure clogging up stdLib with it is a good idea. That
>> > said, I
>>> > >suppose if one saves window positions from launch to launch, it
>> > could come
>>> > >in handy to make sure the display config hasn't changed and a
>> > window is
>>> > >positioned 'off screen.' I know for instance the 3.0 Rev IDE could
>> > use it as
>>> > >sometimes the Rev Help stack get's positioned off screen (after a
>> > crash)>
>>> > >They should check any IDE stacks'
>> > "isStackCurrentlyVisibleOnAnyMonitor" when
>>> > >opening it.
>>> > >
>>> > >In anycase, please know it's fine with me if you don't include it.
>>> > >
>>> > >-Chipp
>> >
>> > May be we should consider having two libs, stdLib for commonly used
>> > stuff and utilLib for stuff needed sporadically or in special
>> > circumstances only. isStackCurrentlyVisibleOnAnyMonitor is indeed a
>> > candidate for the latter.
>> >
>> > Robert
>> >
>
>
>



[Non-text portions of this message have been removed]

I'm all for two libraries. A Utility library might interest more than
a few people if it provided enough utilities.

Tom McGrath

On Sep 26, 2008, at 5:01 PM, Robert Brenstein wrote:

> On 26/09/08 at 14:35 -0500 Chipp Walters apparently wrote:
> >Richard,
> >After you asked that, I got to thinking why would I want this
> function in
> >stdLib? And in all the years of using Rev, I have never had the
> need to
> >use "isStackCurrentlyVisibleOnAnyMonitor."
> >
> >So, I'm not sure clogging up stdLib with it is a good idea. That
> said, I
> >suppose if one saves window positions from launch to launch, it
> could come
> >in handy to make sure the display config hasn't changed and a
> window is
> >positioned 'off screen.' I know for instance the 3.0 Rev IDE could
> use it as
> >sometimes the Rev Help stack get's positioned off screen (after a
> crash)>
> >They should check any IDE stacks'
> "isStackCurrentlyVisibleOnAnyMonitor" when
> >opening it.
> >
> >In anycase, please know it's fine with me if you don't include it.
> >
> >-Chipp
>
> May be we should consider having two libs, stdLib for commonly used
> stuff and utilLib for stuff needed sporadically or in special
> circumstances only. isStackCurrentlyVisibleOnAnyMonitor is indeed a
> candidate for the latter.
>
> Robert
>

Richard-

Friday, September 26, 2008, 12:03:54 PM, you wrote:

> informal vote:  is this handler something you'd use often enough to
> warrant inclusion in stdLib.rev?

I don't really have an opinion about whether or not this should go
into the stdLib - I think it's a clever hack and I'd like to have it
stashed away somewhere, but I don't know if stdLib is the place.

But looking at the code got me to realize that I could use the
screenrects to solve another problem, so I've already benefitted from
this function, whether it's in stdLib or not. Thanks, Chipp.

--
-Mark Wieder
  mwieder@...

> Chipp has granted permission for its inclusion in stdLib.rev, but
> before we do that I thought I'd run it past you folks here for an
> informal vote:  is this handler something you'd use often enough to
> warrant inclusion in stdLib.rev?

I have a similar function I use called "isOnScreen" but I've only used it
for one project so far, so IMHO it's not something I'd use often enough for
stdLib.

Ken Ray
Sons of Thunder Software, Inc.
Email: kray@...
Web Site: http://www.sonsothunder.com/

On Sep 26, 2008, at 2:03 PM, Richard Gaskin wrote:

>  wrote a nifty and very complete handler for determining if a
> stack is visible to the user, named
> "isStackCurrentlyVisibleOnAnyMonitor".



and Chipp said:

> After you asked that, I got to thinking why would I want this
> function in
> stdLib? And in all the years of using Rev, I have never had the need
> to
> use "isStackCurrentlyVisibleOnAnyMonitor."


Me neither. Though I can imagine—vaguely—a circumstance where I might
want to. But then I'd probably also want to tweak it so that I would
know which monitor the stack was visible on, or whether the stack was
sufficiently visible (not a single corner pixel). So I'd vote "no" but
the handler might be good inclusion for a "snippets" site.


t

On 26/09/08 at 14:35 -0500 Chipp Walters apparently wrote:
>Richard,
>After you asked that, I got to thinking why would I want this function in
>stdLib? And in all the years of using Rev, I have never had the need to
>use "isStackCurrentlyVisibleOnAnyMonitor."
>
>So, I'm not sure clogging up stdLib with it is a good idea. That said, I
>suppose if one saves window positions from launch to launch, it could come
>in handy to make sure the display config hasn't changed and a window is
>positioned 'off screen.' I know for instance the 3.0 Rev IDE could use it as
>sometimes the Rev Help stack get's positioned off screen (after a crash)>
>They should check any IDE stacks' "isStackCurrentlyVisibleOnAnyMonitor" when
>opening it.
>
>In anycase, please know it's fine with me if you don't include it.
>
>-Chipp

May be we should consider having two libs, stdLib for commonly used
stuff and utilLib for stuff needed sporadically or in special
circumstances only. isStackCurrentlyVisibleOnAnyMonitor is indeed a
candidate for the latter.

Robert

Richard,
After you asked that, I got to thinking why would I want this function in
stdLib? And in all the years of using Rev, I have never had the need to
use "isStackCurrentlyVisibleOnAnyMonitor."

So, I'm not sure clogging up stdLib with it is a good idea. That said, I
suppose if one saves window positions from launch to launch, it could come
in handy to make sure the display config hasn't changed and a window is
positioned 'off screen.' I know for instance the 3.0 Rev IDE could use it as
sometimes the Rev Help stack get's positioned off screen (after a crash)>
They should check any IDE stacks' "isStackCurrentlyVisibleOnAnyMonitor" when
opening it.

In anycase, please know it's fine with me if you don't include it.

-Chipp

On Fri, Sep 26, 2008 at 2:03 PM, Richard Gaskin
<Ambassador@...>wrote:

> Chipp wrote a nifty and very complete handler for determining if a
> stack is visible to the user, named "isStackCurrentlyVisibleOnAnyMonitor".
>
> The handler was discussed on the use-rev list, and Robert Brenstein
> suggested perhaps it might make a good addition to stdLib.rev.
>
> Robert's post with the full handler by Chipp is here:
>
> http://lists.runrev.com/pipermail/use-revolution/2008-September/115175.html
>
> Chipp has granted permission for its inclusion in stdLib.rev, but
> before we do that I thought I'd run it past you folks here for an
> informal vote:  is this handler something you'd use often enough to
> warrant inclusion in stdLib.rev?
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Chipp wrote a nifty and very complete handler for determining if a
stack is visible to the user, named "isStackCurrentlyVisibleOnAnyMonitor".

The handler was discussed on the use-rev list, and Robert Brenstein
suggested perhaps it might make a good addition to stdLib.rev.

Robert's post with the full handler by Chipp is here:

http://lists.runrev.com/pipermail/use-revolution/2008-September/115175.html

Chipp has granted permission for its inclusion in stdLib.rev, but
before we do that I thought I'd run it past you folks here for an
informal vote:  is this handler something you'd use often enough to
warrant inclusion in stdLib.rev?

2008/8/31 Ken Ray <kray@...>

> Thanks for posting this, David... it's a good topic for this group.
>
> > *Background*
> > I put a lot of effort into abstracting out code into generic libraries,
> and
> > there is always a battle between making the code simple and generic, and
> > making it flexible enough to all the uses it could be put to. What tends
> to
> > happen is that the handlers steadily sprout parameters, and what started
> > simple ends up requiring a big manual to get your head around.
> >
> > I separate my code now into a semi-strict structure with the visual code
> in
> > the controls - libraries in used stacks, and the program logic on the
> card
> > script.
>
> Can you clarify what you mean by this? When you say "the visual code in the
> controls", what do you consider "visual code"?


Any code that relates to the visual appearance of the view displaying data
or interacting with the user. Typically code relating to things like
geometry, or colours or other visual styles. This is contrasted with code
that fetches or manipulates the actual data, or code involved in the logic
of the particular application. So yes - I keep this visual code separate -
either in the "views" themselves (usually groups taken from a library), or
abstracted into a library that multiple views can share.

separating your code, you're talking about separating it for a full project,
> and not just for libraries, right? (Just trying to be clear.)


Yes - in particular I am finding the separation of visual code from the
program logic helpful. Not just used stacks or front / back scripts - but
more interestingly I have started to put all program logic in the card
script (sometimes stack script) - but never in the card based groups or
controls. The acid test here is always can I replace a control on the card
with an updated version, or a different style of control and everything
still keep working. Early on I experimented with having custom scripts
sections that would be saved and restored when the view is updated /
replaced - but now I find I nearly always can do what I want and keep the
code on the card script.

So if I'm understanding you properly, the reason why this:
>
>   put the graph_NodeColour [nodeID] of the target into someColour
>
> is preferable to this:
>
>   put the uOPN["NodeColour"] of the target into someColour
>
> is because the end user can intercept the getProp to run custom code if
> they
> wanted to do something other than just set the one `uOPN["NodeColour"]` of
> the target?
>
> If so, then why couldn't the end user simply intercept the getProp on the
> `uOPN["NodeColour"]` instead of intercepting the getProp of
> `graph_NodeColour[nodeID]` ?


Not really. The main point of the post was the use of custom property calls
from the library down to the visual controls as a form of end user
customisation. The choice of doing this with explicitly wrapped handlers is
not important. I do this for readability - I find that if I don;t use
getprop / setprop handlers I cannot tell by looking at the code - I miss
part of the program logic visually. I prefer to be able to see this by
looking at the organisation of the handler in the handler list. I use uOPN
to indicate that this is an actual custom property and to ensure
compatability in cases where there may be other people code mixed in.

>
> >> end graph_NodeRect
>
> I'm assuming the custom props above should be `uOPN["NodeShape"]` and
> `uOPN["NodeRect"]` instead of `uOPN["NodeColour"]`, right? (I'm assuming
> it's just a copy-and-paste error... something I do all the time ;-)


Yes sorry - just a typo.

Well, here's my two cents... and keep in mind that I may very well be
> reacting from an engrained development approach... but it *seems* to me to
> be a bit more abstracted than it needs to be (IMHO). I like the idea of
> custom property-trapping in order to allow the end-user/developer to add
> custom behaviors,


Thats the main point really.


> but I guess I'm struggling with the additional
> abstraction.


  I did not mean to emphasise that.

Here's an example: I have a library called "libSTSControls" that manages
> custom controls (like a splitter object or a search box), that exist as
> groups on the card of the main stack of the library. When a new "splitter"
> is needed, I have a handler that can be called which will create a copy of
> that splitter control on the current card:
>
>  stsControls_Create "splitter"


Similar.  I have a database of views. Each view is in its own stack, and
stored together in a folder. They are named so that they are structured
hiearchicly - so the are Title Views ("View|Title|Simple" or
"View|Title|Icon"), there are layout views, form views, teree views, image
views, etc. Then I have a generic library to insert, delete, and update the
views. So in your example above I would.

set the view_Insert of group "layout" of card 2 to "View|Simple|Tree"

Which in turn generates an "stsControls_NewControl" message with params
> about the type of object being created, and if it is not trapped by any
> user's code, it hits the "backstop" in the library:
>
>  on stsControls_newControl
>  end stsControls_newControl


I think that the same - I use a front script which checks the uRIPs and if
its a view - stores or updates info in the database. The front script is
passed and does not affect the ability to trap the messages locally.

Each custom control (group) has a uRIP["type"] that corresponds to the type
> of control (like "STSSplitter") so that if I have any code that needs to
> see
> how many splitters are on a card, say, it can quickly iterate through the
> groups on the card and check the uRIP["type"] of each group.


I use uRIP["type"] for "library" or "view" or "menu" - its underused really
and I use the uRIP["name"] for a full path like "View|Title|Simple". Maybe I
should use "type" for that.

The getprop/setprop for this property lives in the library, not in the group
> itself - in fact, I prefer to keep my custom controls codeless so they are
> only a group of objects and custom properties to control them.


Yes. I also have stopped storing data in the views that may change. I use
the card script now as a default. I do however put the logic for things like
geometry inside the view (group). I like to be able to go into the code and
tweak it, and I don't like the Rev based way of using libraries and custom
properties - again I like the readability of the code. So I leave code in
the view that has to do with visual presentation and is relatively stable.

The code in the library always refers to "the target",


Again I use custom properties for how you refer to things - so instead of:

  put the text of the target

  you'd either have

  put the tree_Text of the target

, or

put the text of the tree_Field of the target.


[Non-text portions of this message have been removed]