Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

help!! image => clipboard:// WAS{Re: Re: Ready for REBOL/Core 2.6?}

 [1/7] from: jason:cunliffe:verizon at: 8-Mar-2002 16:04


> > Will the next release of /View support binary data via clipboard:// ? > > Image data ? Possibly. The problem is that this is highly
platform-dependent. Holger PLEASE: Yes, I realize RT leans towards an all-or-nothing [platform neutral] policy. The deep Catch-22 is that for desktop-type interactions, ie: people using mice, 'some is waaay better than 'none. Win32/MacOSX/Linux/others [..in roughly that order] IMO, /View's image built-in graphics processing is of trivial use unless desktop apps can integrate well with people's other workflow environment. That means cut'n'paste. Since 15++years, cut'n'paste between media software is fully expected, with Drag'n'drop catching up solidly in past 6 years. CRTL [MacCMD] + Z | X | C | V functions are one of the implicit cornerstones of GUI computing. It's an individal choice whether or not to use mouse, menu or buttons. Any decent tool offer redundancy sensibly. For me, without image clipboard capability, /View has no real future. It's a deal breaker [not weaving but drwoning]. I am sorry to be so dramatic, but have been struggling with this for issue a while now. I can'tsee any way round it. I hope others will express their opinions. regards ./Jason

 [2/7] from: greggirwin:mindspring at: 8-Mar-2002 16:29


Jason, et al I can see both sides. I understand the importance of cross-platform consistency but it's a feature I could really use. The problem comes when we get it for Win32 and then complain that our users running on platform-X can't use our app. RT is between a rock and hard place. --Gregg

 [3/7] from: carl:cybercraft at: 9-Mar-2002 12:39


On 09-Mar-02, Jason Cunliffe wrote:
>> > Will the next release of /View support binary data via >> > clipboard:// ?
<<quoted lines omitted: 23>>
> I can'tsee any way round it. I hope others will express their > opinions.
I agree entirely with you Jason. Very well argued.
> regards > ./Jason
-- Carl Read

 [4/7] from: petr::krenzelok::trz::cz at: 9-Mar-2002 0:45


Jason Cunliffe wrote:
>>>Will the next release of /View support binary data via clipboard:// ? >>>
<<quoted lines omitted: 20>>
>dramatic, but have been struggling with this for issue a while now. >I can'tsee any way round it. I hope others will express their opinions.
Thare is more to Rebol and cross platform issues. Maybe one day RT discards View at all, as MS will do everything thru DirectX, which is not available on other platforms ;-) Well, I remember the discussion regarding keyboard. Simultaneous key presses can't be have in Rebol, because not all platforms support it (or simply it was some other issue, but there was some limitation re cross platform issues). Ask Cyphre how he struggled building his Arcadia engine. For me - the boundary of supported vs non supported platform feature is blurred, but Holger holds another opinion here :-) But I will not change my mind: - try to open sound port on a machine, not having sound card - it fails. Being it OS dependant or hw dependant, from the user's pov it is irrelevant. It is simply "lack of feature of OS/HW platform Rebol runs on" - Rebol already supports platform dependant issues: Taken from the doc: REBOL 2.5 provides the ability to specify the fork of Macintosh files. This is done with the custom READ and WRITE settings. (eg: read/binary/custom %file [fork resource"])" Small test what the feature does under Widnows: ->> read/binary/custom %user.r [fork "resource"] ** Access Error: Cannot open /C/REBOL/View/user.r ** Near: read/binary/custom %user.r [fork "resource"] ->> read/binary %user.r == #{ 5245424F4C205B0D0A202020205469746C653A20225573657220507265666572 656E63657322200D0A20202020446174653A20342D5365702D323030302F... So, if above code works under MacOS, it IS definitely platform dependant feature available in Rebol. Will I complain it fails on Windows? No, because I do understand, that Mac users will find it usefull. As you stated - having SOME option, is still far better, than having NO option, of how to solve certain situation. -pekr-

 [5/7] from: brett:codeconscious at: 9-Mar-2002 11:44


I think clipboard provides a basic manual level of integration with other software that the user understands - even with its vagaries of usefulness between applications. My work with View hasn't seen me do a lot of image transfers to/from other programs but when I have done them I immediately thought of clipboard first. As for handling the content management of clipboard, I don't know what the other platforms do, but my understanding is that Windows allows multiple formats to be registered/provided. Providing this level of functionality is only useful when the programmer takes on the responsibility to load/serialise/manage the various formats. Which leads me to another thought. Aside from the non-Rebol platform/software compatibility issue, Rebol apps can pass information around easily because of the way that Rebol can/will serialise values. I wonder whether there is some coordination or conventions that could make clipboard transfers amongst Rebol applications must more useful and intelligent? After all, my personal preference goal is to be productive with Reblet to Reblet sharing rather than currently Reblet to MS/other. All in all, View/Link support for clipboard integration with other apps is probably a necessary evil until users can/will migrate their workflows to Rebol applications. Brett.

 [6/7] from: carl:cybercraft at: 9-Mar-2002 15:00


On 09-Mar-02, Gregg Irwin wrote:
> Jason, et al > I can see both sides. I understand the importance of cross-platform > consistency but it's a feature I could really use. The problem comes > when we get it for Win32 and then complain that our users running on > platform-X can't use our app. RT is between a rock and hard place.
But if a particular OS has no support for a gfx clipboard its users are not going to expect to be able to cut and paste between REBOL and non-REBOL apps, are they? Perhaps with such OSs a specific View-only clipboard could be somehow implimented. (Don't ask me if that's possible though:) Then View scripts would function the same, but they'd just be for cutting and pasting between REBOL apps. -- Carl Read

 [7/7] from: jason:cunliffe:verizon at: 9-Mar-2002 6:35


> But if a particular OS has no support for a gfx clipboard its users > are not going to expect to be able to cut and paste between REBOL and > non-REBOL apps, are they? Perhaps with such OSs a specific View-only > clipboard could be somehow implimented. (Don't ask me if that's > possible though:) Then View scripts would function the same, but > they'd just be for cutting and pasting between REBOL apps.
yes Right. ..a very reasonable strategy. It never ceases to surprise me how many applications have undocumented or un-evident cut'n'paste attributes. come to think of it, Rebol/View is a good example. You just have to try or know that it works ;-) Powerpoint and Flash have good cutnpaste implementations. So does the amazing, intuitive Vegas Video editing system by Sonic Foundry http://sonicfoundry.com/products/NewShowProduct.asp?PID=612 ./Jason

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted