Re: ScreenRect bug or not
Richard- Thursday, June 5, 2014, 7:19:07 AM, you wrote: There is an IDE rewrite underway, and a very large-scope effort to improve overall rendering. Eh? One of the problems with being OCD about my LiveCode consumption is that I can no longer recall where I hear things, whether it was in a newsletter article, a blog post, or the Global Jam chats Kevin and Ben hosted. The IDE rewrite is AFAIK very early-stage, a logical necessity from the Open Language initiative and the implications thereof related to extensibility. I imagine we'll be hearing more about it as it begins to move from sketchpad to code, but right now it's all about supporting OL so I don't believe there's much concrete that can be said about it until OL gets fleshed out more. If there's a secret project going on behind the scenes to produce a new IDE, out of sight of the github process, then it's hardly worth the effort to ferret out fixes to existing bugs. -- -Mark Wieder ahsoftw...@gmail.com This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Mark Wieder wrote: Richard- Thursday, June 5, 2014, 7:19:07 AM, you wrote: The IDE rewrite is AFAIK very early-stage, a logical necessity from the Open Language initiative and the implications thereof related to extensibility. I imagine we'll be hearing more about it as it begins to move from sketchpad to code, but right now it's all about supporting OL so I don't believe there's much concrete that can be said about it until OL gets fleshed out more. If there's a secret project going on behind the scenes to produce a new IDE, out of sight of the github process, then it's hardly worth the effort to ferret out fixes to existing bugs. Mark, you're one of the smartest people I know, so I'm having a hard time understanding why would you choose such an unnecessarily emotionally-laden word like secret? A secret is a willful attempt to conceal, but we have no indication that anyone's doing that. So before anyone runs off to the hardware store to grab pitchforks for storming the castle over some imagined IDE conspiracy, please kindly take a moment to consider only what I wrote, and I'll try to make it even clearer here: AFAIK there is no other RunRev-borne IDE in existence (the community has several), just ideas, sketches, possibilities and imaginings which may become fleshed out into some actual thing in the future once Open Language is far enough along to make such a necessary change in the IDE to support it achievable. And as we all know, Open Language is among the least-urgent of all the Kickstarter goals, so don't expect it before critical fixes like Unicode, Cocoa, and multimedia are solidly completed. And don't expect any IDE that depends on Open Language until Open Language is far enough along to be dependable. So in the meantime, the core dev team uses the same IDE as the rest of us. And even when a new IDE project can be started on the foundation of a nearly-completed Open Language-based engine, we can anticipate that moment will be many months from now, and will take many months more to complete, so any work done on the current IDE seems likely to have a useful shelf life. -- Richard Gaskin LiveCode Community Manager richard at livecode.org ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
On 6/8/2014, 1:28 PM, Richard Gaskin wrote: AFAIK there is no other RunRev-borne IDE in existence (the community has several), just ideas, sketches, possibilities and imaginings which may become fleshed out into some actual thing in the future The idea for a new IDE was announced two RevLives ago (the time you missed Richard, but you sent a video and a random drawing prize.) I thought the new project browser was the first step in that direction. Then other things came up with more urgency and the PB is, so far, the only piece we have. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Richard- Sunday, June 8, 2014, 11:28:28 AM, you wrote: A secret is a willful attempt to conceal, but we have no indication that anyone's doing that. So before anyone runs off to the hardware store to grab pitchforks for storming the castle over some imagined IDE conspiracy, please kindly take a moment to consider only what I wrote Here is what you wrote: There is an IDE rewrite underway, and a very large-scope effort to improve overall rendering. As you know, I've been pushing for open-sourcing the IDE for over a year now, but so far I've seen no move in that direction. If you're privy to some information that the rest of us are not, then perhaps you have a better word for it than secret, because it's certainly news to me. I recall some years ago there was a decision by the team to rewrite the datatbase library, and so all existing database bugs were closed and made duplicates of a single db-rewrite bug. To date all those bug reports remain in the limbo of duplicate entries and the database layer has not been rewritten. I trust it will happen someday, but in the meantime I'm not about to try fixing database layer bugs just to have them closed as duplicates. And I don't see any difference with the rest of the IDE if we don't know what parts are being rewritten. ...although possibly you mean something else by IDE rewrite... -- -Mark Wieder ahsoftw...@gmail.com This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Mark Wieder wrote: Richard- Sunday, June 8, 2014, 11:28:28 AM, you wrote: A secret is a willful attempt to conceal, but we have no indication that anyone's doing that. So before anyone runs off to the hardware store to grab pitchforks for storming the castle over some imagined IDE conspiracy, please kindly take a moment to consider only what I wrote Here is what you wrote: There is an IDE rewrite underway, and a very large-scope effort to improve overall rendering. One of the problems with my admittedly-lengthy writing style is that it can make posts too long to read - I had also written: The IDE rewrite is AFAIK very early-stage, a logical necessity from the Open Language initiative and the implications thereof related to extensibility. I imagine we'll be hearing more about it as it begins to move from sketchpad to code, but right now it's all about supporting OL so I don't believe there's much concrete that can be said about it until OL gets fleshed out more. AFAIK there is no version of the engine in any usable form that supports Open Language (on the contrary, I would imagine there are many deep design decisions still being fleshed out), so it would not be possible for the folks at RunRev to be secretly using an IDE dependent on it. As Jacque noted, the core dev team has been discussing plans for a new IDE for a long time. Evolution of features and design are an inherent part of the process for all software, and a glance at the Road Map makes it clear that it will only become increasingly necessary for RunRev as well. I just think it'll be more productive if we can discuss future development options with a presumption of good intentions. As you know, I've been pushing for open-sourcing the IDE for over a year now, but so far I've seen no move in that direction. If you're privy to some information that the rest of us are not, then perhaps you have a better word for it than secret, because it's certainly news to me. If something is merely unknown, using unknown may be a good choice. :) As the current acting Community Manager, the nature of the role requires me to help find ways to remove obstacles that may be preventing anyone from doing what they want to do in this open source project. To recap where we are with the IDE in terms of open source process: The IDE files are on GitHub, and even better are licensed under the very permissive MIT license: https://github.com/runrev/livecode-ide/blob/master/IDE%20License.txt We use LiveCode because it represents a very different way of working, but that same benefit for us poses unique challenges as an open source project. As you know better than most, off-the-shelf versioning systems don't handle LiveCode's unique structure for stack files, leaving it for us to invent our own way to make that happen. Good work has been done along those lines (and a lot of that by you - thank you for helping to bring it as far as it's come), and many options exist for ways to do productive work even now, before we have an even better system in place. But ultimately the bigger issue here isn't a technical one of all, but the central challenge with all open source projects: Finding people with the time and skills to contribute. The skills required go beyond just LiveCode proficiency. As with any open source project, there has to be a willingness to work within a wide range of divergent interests and goals, and a sometimes-dizzying variety of design visions. Very few of us in the LiveCode universe have much hands-on experience with this sort of process. I've made only modest contributions to the Ubuntu project (and thankfully none of them in C++ code g), most of LiveCode's user base makes and uses only proprietary software, and RunRev themselves have been open source just over a year. We're all learning as we go. It complicates things further that the nature of LiveCode stack files currently precludes us from easily using off-the-shelf systems to help support the process. But I still believe we can do it. There are some very smart, inventive people both here in the community and on the core dev team, and we all share the common vision of both sides working together productively to make the best LiveCode the world has seen. To help this along, we have the good fortune of having bugs in the IDE, which are of course annoying but also allow us an opportunity: If we prioritize addressing bugs in the current IDE right now, we'll not only have fewer bugs, but more importantly we will have found the team members and processes that can guide bigger objectives. This email has already gotten too long, so let me outline some of the ways we can work on the IDE today in a separate post. -- Richard Gaskin LiveCode Community Manager richard at livecode.org ___ use-livecode mailing list use-livecode@lists.runrev.com
Re: ScreenRect bug or not
Mark Wieder Richard- Wednesday, June 4, 2014, 9:48:20 AM, you wrote: There is an IDE rewrite underway, and a very large-scope effort to improve overall rendering. Eh? One of the problems with being OCD about my LiveCode consumption is that I can no longer recall where I hear things, whether it was in a newsletter article, a blog post, or the Global Jam chats Kevin and Ben hosted. The IDE rewrite is AFAIK very early-stage, a logical necessity from the Open Language initiative and the implications thereof related to extensibility. I imagine we'll be hearing more about it as it begins to move from sketchpad to code, but right now it's all about supporting OL so I don't believe there's much concrete that can be said about it until OL gets fleshed out more. The rendering optimization has been ongoing for many builds, begun with acceleratedRendering and tiling, and continued with the introduction of Skia as the 2D graphics subsystem. Because Skia is layer-based, the benefits of the tiling method are somewhat limited, so the team is exploring a more with-the-Skia-grain approach of focusing on buffered layers instead. I'm not familiar with the intricacies, but given that so much of LiveCode's logic is layer-based I have to imagine this will bode well as a more flexible approach over the long term. Much of the initial rendering optimization was focused on the needs of mobile platforms, but as Kevin reminds us most of the engine stuff for mobile tends to benefit all platforms. Desktop apps are increasingly using dynamic Metro-style layouts, and even now we can see significant improvement with things like moving multiple objects simultaneously (even on Linux, where rendering speeds used to be abysmal). I don't know the specific status of the layer-based optimization (maybe it's on those Global Jam chat videos), but I'm sure we'll be hearing more about it as it gets further along, either in the daily blog posts or the newsletter. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Well, I give up. This morning I have using LC 6.6.1 been through all my Geometry settings to double check everything is working correctly. After a few adjustments the Geometry settings are correct. Set LC 6.6.1 to liveResize = false and resizable = true. Geometry settings worked as expected when dragging the bottom right of the stack window. Clicked on the green traffic light and the stack window zoomed to a very odd size with the bottom right set to the bottom right of the screen with a gap on the left similar to the width of the tools palette(which is on screen)with a similar gap between the underside of the menubar and the top of the stack window (icon palette not on screen). Gave up at that point and switched to LC 6.7 (dp 4) LC 6.7 still has liveResize = false and resizable = true. Assumed Geometry settings will not have changed. Dragging by the bottom right of the stack window I noticed that liveResize was active despite the setting being false? Is that another bug? Clicked on the green traffic light and the stack window resized to what I expected, that is directly beneath the menubar and the size of the screen. I cannot identify what is wrong with the resizing of stack windows as for me there is no discernible pattern but clearly there is something amiss. I hope it gets cleared up in the not to distant future. All the best Terry On 3 Jun 2014, at 20:51, Paul Hibbert paulhibb...@mac.com wrote: My test agree with Richard's and confirms this as a bug in LC6.7(DP4), seems OK in other versions so it may be something to do with the Cocoa implementation, adding an extra line gets round the problem until it's fixed… ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Terence Heaford wrote: This morning I have using LC 6.6.1 been through all my Geometry settings to double check everything is working correctly. After a few adjustments the Geometry settings are correct. Set LC 6.6.1 to liveResize = false and resizable= true. Why set liveResizing to false? Live resizing is very much the convention these days. Even Apple's Garage Band, which has the slowest resizing behavior I've ever seen, does live resizing. LiveResizing doesn't affect metrics; all it does it allow your stack to receive resizeStack events during the resize, rather than just getting one message when the resizing has completed. Clicked on the green traffic light and the stack window zoomed to a very odd size with the bottom right set to the bottom right of the screen with a gap on the left similar to the width of the tools palette(which is on screen)with a similar gap between the underside of the menubar and the top of the stack window (icon palette not on screen). This is not a bug, but a design decision. I don't agree with it myself, at least not as far as the left edge goes, but it's only this way in the IDE and is fully settable by the scripter. The key here is the windowBoundingRect global property - worth a visit to the Dictionary. By default it should be set to give you an appropriate full-screen zoom without modification, but you can modify it to accommodate things like toolbars if you like, which is what RunRev has done in the IDE. Personally I think they should have left the left edge well enough alone (after all, the Tool palette is movable, and really only needed for a relatively short time during development, in the early stages when you're still laying out controls). But the top modification is essential, for the reasons the windowBoundingRect was added, to allow us to support zoomable windows that don't submarine below the toolbar. Gave up at that point and switched to LC 6.7 (dp 4) LC 6.7 still has liveResize = false and resizable = true. Both of those properties are persistent so it's good to know they're being preserved as expected even in that deeply-modified test version. Dragging by the bottom right of the stack window I noticed that liveResize was active despite the setting being false? Is that another bug? If it's a newly created stack you'll find that liveResizing is now on by default for the last several versions. It really is the norm, so this decision just makes it one step easier for us to make modern-looking apps, and as I noted doesn't affect metrics in any way, only the frequency of resizeStack messages. If this is a stack which had its liveResizing off in earlier builds, and still shows liveResizing off even though it's exhibiting this behavior, this may be yet another case where Cocoa's assumption that the only thing you'll ever want to do is complete compliance with the OS X Human Interface Guidelines is making it hard to do anything else, and would warrant a bug report if one hasn't been filed for that test build already. I should note that as valuable as it is for all of us to help with testing, v6.7 is a VERY exotic build, the first that uses Cocoa, meaning the first to attempt to merge LiveCode's object and messaging model with the limited and often strictly-enforced Cocoa way of doing things. While you're still learning the nuances of all the flexibility LiveCode provides for window metrics, it may be best to stick with 6.6.2, which is also a test build but without the extreme changes Cocoa requires, and also very late-stage to it's quite stable and enjoyable to work with, in my experience. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Thanks for your detailed reply. I am pretty sure Live Resizing should be the standard way of doing things but I have to say that LC’s performance in this area is quite poor. I have my stack at a small size to improve the scrolling speed of a table but when I switch to another card that displays charts it is sometimes preferable to have a larger chart which I have created in a group. I have to redraw the charts when the stack is resized and this is where LC’s performance is poor. The stack stutters slightly as it is resizing. Now for some heresy. I also have Xojo (purchased with the last offer for £12) with the same programme running and this does not have the stutter LC does. I just mentioned this to eliminate my computer (Macbook Pro 2.4 late 2008 unibody, hopefully due for change this summer) from the equation. I really prefer scripting to Objective-C and Xojo because I have worked with SC for so long but always seem to come up against a performance limitation at some point. Ah well. I don’t know if you remember the discussions over DataGrid and the Basic Table Field but pending release of the update to the Basic Table Field to include for right alignment I have changed to this control because of the improved scrolling speed when compared to the DataGrid. Interestingly while testing the stack in LC 6.7(dp4) I have noticed a significant increase in scrolling speed of the Basic TableField in the order of a 15-25% improvement when compared to LC 6.6.1. Within this stack I have pie charts created out of LC objects and having just measured the milliseconds from the start of creation to display, there is a 12% improvement comparing LC 6.7 with LC 6.6.1. I am presuming this is because of a change to Cocoa and streamlining the base code of LC. This is a significant improvement which I hope would be maintained and perhaps improved further as the Cocoa based LC progresses? Do you know which version will be the first to receive the right alignment in the Basic Table Field? Also while on the subject of speed (perhaps another thread) but is there an intention to speed up the script editor as I find the scrolling painful? All the best Terry On 4 Jun 2014, at 15:57, Richard Gaskin ambassa...@fourthworld.com wrote: I should note that as valuable as it is for all of us to help with testing, v6.7 is a VERY exotic build, the first that uses Cocoa, meaning the first to attempt to merge LiveCode's object and messaging model with the limited and often strictly-enforced Cocoa way of doing things. While you're still learning the nuances of all the flexibility LiveCode provides for window metrics, it may be best to stick with 6.6.2, which is also a test build but without the extreme changes Cocoa requires, and also very late-stage to it's quite stable and enjoyable to work with, in my experience. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Terence Heaford wrote: I am pretty sure Live Resizing should be the standard way of doing things but I have to say that LC’s performance in this area is quite poor. I have my stack at a small size to improve the scrolling speed of a table but when I switch to another card that displays charts it is sometimes preferable to have a larger chart which I have created in a group. I have to redraw the charts when the stack is resized and this is where LC’s performance is poor. The stack stutters slightly as it is resizing. I've seen things like that now and then, rarely as bad as Apple's Garage Band but below what I like to give to customers. Fortunately, in each case I found things I was doing in my scripts that caused redundant redraws - once I fixed those, even complex layouts with multiple DataGrids were pretty smooth. DataGrids are a very challenging case, consisting as they do of so many controls. Since you're only using the native field object I'll bet we can get your layout resizing very nicely. Are you able to post the stack somewhere, or at least the resizeStack handler so we can see what it's doing? Now for some heresy. I also have Xojo (purchased with the last offer for £12) with the same programme running and this does not have the stutter LC does. You won't hear cries of heretic! from me. Most of us use multiple languages. I've been in the biz long enough that I no longer use proprietary formats for anything I care about (seen too many apps come and go, and I need to truly own my data), but the other half of my time is spent in JavaScript, and lately a lot of bash. Learning new things keeps us youthful. :) Each language exists becomes it does something better than the others, but none of them is a magic pony, not even LiveCode, nor Objective C nor anything else. In terms of performance, with Xojo's data typing requirements we'd expect better performance in some areas of raw computation, like image convolvers. But in other areas, like text parsing, the showdown we had here a while back was more or less a wash, which we would also expect because much of what we do in LiveCode is really just triggering highly-optimized routines in the engine that were written in C++ and compiled with the super-smart Clang. Rendering is in many respects language-independent, driven by factors far more complex taking place at a higher level of the implementation. I really prefer scripting to Objective-C and Xojo because I have worked with SC for so long but always seem to come up against a performance limitation at some point. Ah well. In recent years Mark Lucas has done some great work on SC, and if it covered as many platforms as LiveCode I'd probably still be using it today. But Mr. Lucas is very passionate about OS X, and his opinion about Windows and its API is, well, let's just say not suitable for posting here. :) I don’t know if you remember the discussions over DataGrid and the Basic Table Field but pending release of the update to the Basic Table Field to include for right alignment I have changed to this control because of the improved scrolling speed when compared to the DataGrid. Interestingly while testing the stack in LC 6.7(dp4) I have noticed a significant increase in scrolling speed of the Basic TableField in the order of a 15-25% improvement when compared to LC 6.6.1. Within this stack I have pie charts created out of LC objects and having just measured the milliseconds from the start of creation to display, there is a 12% improvement comparing LC 6.7 with LC 6.6.1. Not surprising, given the attention the team has been putting into the rendering algos. Have you benchmarked 6.6.2rc6? While the changes aren't as deep as in later test versions, you may still see a boost from improvements to the tiling algo they use. I am presuming this is because of a change to Cocoa and streamlining the base code of LC. Not necessarily. In fact, I'd be surprised if Cocoa made very many things faster in itself, since Cocoa is only optimized for strictly-HIG-compliant layouts, and doesn't play nice with the sort of flexibility LiveCoders demand. For example, consider the infamous pulsing default button: Any animated effect will take more CPU load than a static one, and even Apple's best effort in their own apps tends to bump CPU load by about 8-9% whenever a pulsing default button is visible on screen. But their API for this insists on antialiasing only against a blank region of the window using whatever default background pattern/color they happen to be using in that version. Try telling anyone using an xTalk that they can't put a default button on top of a graphic, or an image, or even a movie if they like. We xTalkers are used to having this level of flexibility, but it would mean antialiasing artifacts if the engine used only the OS routines. So instead the engine has to do an extra step, rendering the
Re: ScreenRect bug or not
Richard- Wednesday, June 4, 2014, 9:48:20 AM, you wrote: There is an IDE rewrite underway, and a very large-scope effort to improve overall rendering. Eh? -- -Mark Wieder ahsoftw...@gmail.com This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
ScreenRect bug or not
Mac OS X 10.9.3 LC 6.6.1 LC 6.7 (dp4) I have been zooming a stack to the size of the screen using the screenRect function: set the rect of this stack to the working screenRect When I do this the top part of the stack window disappears beneath the OS X menubar. The documents suggest it should be otherwise: Adding the working adjective to either form returns the virtual co-ordinates of each screen's working-area. The working-area of a screen is defined to be the area not covered by OS furniture (such as the task bar on Windows, and the Dock and Menubar on Mac OS X).” Is this a bug or are the documents incorrect. If the documents are incorrect then is there a LC function that returns the height of the Mac menubar? All the best Terry ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
In my case the working screenRect returned 0,22,1680,1046 if I add 22 to item 2 for 0,44,1680,1046 it seems to work correctly Having measured the screen with Apples screen grab the point directly below the OS X menubar is 22 and not 44. Surely LC should return the correct co-ordinate for Mac and not rely on me converting a Windows co-ordinate? All the best Terry On 3 Jun 2014, at 18:38, Terence Heaford t.heaf...@btinternet.com wrote: Mac OS X 10.9.3 LC 6.6.1 LC 6.7 (dp4) I have been zooming a stack to the size of the screen using the screenRect function: set the rect of this stack to the working screenRect When I do this the top part of the stack window disappears beneath the OS X menubar. The documents suggest it should be otherwise: Adding the working adjective to either form returns the virtual co-ordinates of each screen's working-area. The working-area of a screen is defined to be the area not covered by OS furniture (such as the task bar on Windows, and the Dock and Menubar on Mac OS X).” Is this a bug or are the documents incorrect. If the documents are incorrect then is there a LC function that returns the height of the Mac menubar? All the best Terry ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Terence Heaford wrote: In my case the working screenRect returned 0,22,1680,1046 if I add 22 to item 2 for 0,44,1680,1046 it seems to work correctly Having measured the screen with Apples screen grab the point directly below the OS X menubar is 22 and not 44. Surely LC should return the correct co-ordinate for Mac and not rely on me converting a Windows co-ordinate? Of course not. It might be a bug, but before we go there we can notice that difference sounds suspiciously like the height of the Mac OS title bar. In all xTalks the rect of a stack refers only to its content region. In older xTalks (and older versions of LC) proper window placement required us to hard-wire values for the Mac title bar, and query the Win registry for that platform, and adjust accordingly. LiveCode now does this for us with the effective rect, which accounts for the platform-specific window trimmings (title bar, borders, etc.). -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
OK, This script put the working screenRect = the working screenRect put return the effective working screenRect = tRect after msg put return the screenRect = the screenRect after msg Places the following in the msg box the working screenRect = 0,22,1680,1046 the effective working screenRect = 0,22,1680,1046 the screenRect = 0,0,1680,1050 If I now set the rect of this stack to 0,22,1680,1046 then window top bar that contains the traffic lights is hidden beneath the Mac Menubar. If I change it to set the rect of this stack to 0,44,1680,1046” then the traffic lights are positioned correctly below the Mac Menubar. All the best Terry On 3 Jun 2014, at 19:10, Richard Gaskin ambassa...@fourthworld.com wrote: LiveCode now does this for us with the effective rect, which accounts for the platform-specific window trimmings (title bar, borders, etc.). ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Terence Heaford wrote: On 3 Jun 2014, at 19:10, Richard Gaskin wrote: In all xTalks the rect of a stack refers only to its content region. ... LiveCode now does this for us with the effective rect, which accounts for the platform-specific window trimmings (title bar, borders, etc.). This script put the working screenRect = the working screenRect put return the effective working screenRect = tRect after msg put return the screenRect = the screenRect after msg Places the following in the msg box the working screenRect = 0,22,1680,1046 the effective working screenRect = 0,22,1680,1046 the screenRect = 0,0,1680,1050 If I now set the rect of this stack to 0,22,1680,1046 then window top bar that contains the traffic lights is hidden beneath the Mac Menubar. If I change it to set the rect of this stack to 0,44,1680,1046” then the traffic lights are positioned correctly below the Mac Menubar. And if you set the effective rect of the stack: set the effective rect of this stack to the working screenrect ..you get the placement you're looking for without having to know the OS-specific window trimming metrics. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Sorry Richard, set the effective rect of this stack to the working screenrect I don’t, the traffic lights are still hidden beneath the Mac Menubar. All the best Terry On 3 Jun 2014, at 19:47, Richard Gaskin ambassa...@fourthworld.com wrote: And if you set the effective rect of the stack: set the effective rect of this stack to the working screenrect ..you get the placement you're looking for without having to know the OS-specific window trimming metrics. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
Terence Heaford wrote: Sorry Richard, set the effective rect of this stack to the working screenrect I don’t, the traffic lights are still hidden beneath the Mac Menubar. All the best Terry On 3 Jun 2014, at 19:47, Richard Gaskin ambassador at fourthworld.com wrote: And if you set the effective rect of the stack: set the effective rect of this stack to the working screenrect ..you get the placement you're looking for without having to know the OS-specific window trimming metrics. Which version are you using? Here's my results: 6.6.2 RC6: works as documented 6.7 DP4: strange placement (Bug #12593) 7.0 DP6: works as documented -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
On 6/3/2014, 1:32 PM, Terence Heaford wrote: the working screenRect = 0,22,1680,1046 the effective working screenRect = 0,22,1680,1046 the screenRect = 0,0,1680,1050 If I now set the rect of this stack to 0,22,1680,1046 then window top bar that contains the traffic lights is hidden beneath the Mac Menubar. If I change it to set the rect of this stack to 0,44,1680,1046” then the traffic lights are positioned correctly below the Mac Menubar. I think what you want is the effective rect of this stack. The rect of the stack gives you the dimensions including the title bar. The effective rect gives you only the content dimentions. If you subtract item 2 of the effective stack rect from item 2 of the rect of the stack, you'll know the height of the title bar. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
On 6/3/2014, 1:51 PM, Terence Heaford wrote: set the effective rect of this stack to the working screenrect I don’t, the traffic lights are still hidden beneath the Mac Menubar. That's even better than the method I just posted. Odd it isn't working for you, it works here. The title bar is snugged up against the bottom of the Mac system menu. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: ScreenRect bug or not
My test agree with Richard's and confirms this as a bug in LC6.7(DP4), seems OK in other versions so it may be something to do with the Cocoa implementation, adding an extra line gets round the problem until it's fixed… set the effective rect of this stack to the working screenRect set the loc of this stack to (item 1 of the screenLoc),(item 2 of the screenLoc + 20) -- Temp fix for LC6.7(DP4) bug Tested on Mac OS X 10.8.5 Paul On 2014-06-03, at 12:11 PM, J. Landman Gay jac...@hyperactivesw.com wrote: On 6/3/2014, 1:51 PM, Terence Heaford wrote: set the effective rect of this stack to the working screenrect I don’t, the traffic lights are still hidden beneath the Mac Menubar. That's even better than the method I just posted. Odd it isn't working for you, it works here. The title bar is snugged up against the bottom of the Mac system menu. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
