Windows publishing
[1/4] from: jason::cunliffe::verizon::net at: 11-Oct-2002 0:10
Not sure how much this is a Rebol question..
I want a desktop REBOL/View application which can 'publish' to webservices and
other instances of this app running on remote desktops. A major task is handling
images and metadata publishing.
The mode and behavior is specific to the project.
But to make the workflow really open and useful to people, I need my REBOL
application to be directly accessed in the menus of any other applications,
especially graphics ones.
For example Adobe Acrobat once installed means that one can 'print' to PDF from
any application. We need something just like that but, which will 'print'
'save' or 'copy' to REBOL. I think this comes back to the thorny question of
binary copy or lack of.
Plus the debate about Windows DLLs and operating specific system access.
If I can make this work then I an Encap-ed version of it would be released.
Anyone have any ideas what is needed to do this..?
thanks
./Jason
[2/4] from: greggirwin:mindspring at: 11-Oct-2002 11:44
Hi Jason,
<< But to make the workflow really open and useful to people, I need my
REBOL
application to be directly accessed in the menus of any other applications,
especially graphics ones. >>
Good luck. :) Surely it's not impossible to create things like shell
extensions with REBOL, but I think we'll want docs on the system port, and
it will probably not be easy. I haven't looked down that path, and I hadn't
really planned to.
I envision a somewhat different picture of integrating services in apps
versus extending them to call your *particular* service. I'm thinking that
apps will need to be more open and configurable in order to successfully
make use of outside services. For example, writing an add-in for Visual
Basic's IDE was a very specific process, requiring implementation of
specific COM interfaces. In the future, I think the lookup/discovery/join
approach where things need to go (though I have to say that I'm not a
WSDL/UDDI/"web services" guy given the current specs and popular definitions
of such). I hope for a much better solution than what is being hyped right
now, and I think REBOL is a good fit for that kind of solution.
<< I think this comes back to the thorny question of binary copy or lack of.
Plus the debate about Windows DLLs and operating specific system access. >>
I posted my Windows-specific binary clipboard stuff a short time back. It's
basic, to be sure, but works.
--Gregg
[3/4] from: bry:itnisk at: 12-Oct-2002 11:58
>But to make the workflow really open and useful to people, I need my
REBOL >application to be directly accessed in the menus of any other
applications, >especially graphics ones.
When you say you need your application to be accessible via the menu of
other applications, by which I assume that you mean when someone
accesses file/print and the print dialoque opens one of the printers it
can select will be your rebol printer?
Okay that's a complicated thing and I have to run right now to pick up a
cake for a party, but distiller etc. are in the registry under
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print\Printers
You might also like to take a look at your special folders, there should
be one called printers; look at your windows directory printers.htt for
the file which controls the layout of this directory.
Hope this helps, hope also I understood exactly what it was you wanted.
[4/4] from: jason:cunliffe:verizon at: 12-Oct-2002 1:10
> I've no idea what you're up to but don't forget TCP/IP. For example, if it
> is litterally a "publish" menu item you want to add, but your existing
> application has "save to ftp" then could it be done with a save to FTP? Your
> app appears like FTP, but in fact carries out the publish actions you need.
> That sort of thing.
How do you suggest 'save to ftp' from any app?
WEBDAV is a perhaps possibility.. I've not played with it since Zope a couple of
years ago.
My app is for sequencing and routing images and metadata in lovely ways, with
easy flow between desktop and remote sites. REBOL will handle all the transport
and metadata magic. The problem is simply that it depends in part on the
wonderful basic functionality we've all had for 15 years using multimedia
cutnpaste. Several applications open..
CTRL+C
ALT+TAB
CTRL+V done!
Now if a Rebol app can catch the clipboard correctly, I won't even need to do
more than perform the initial copy in some app. It will be easy to do all the
rest. There are tons of 3rd party Windows clipboard tools out there which do
cool and useful things, some with multiple clipboard buffers.
In my case I want to end up with a *viewable* list/sequence in REBOL/View app of
all the things I have copied elsewhere. Then edit/addmetada and zing-o-publish.
Defaults and template stuff will make a lot of this automatic and run in the
background. Rugby will no doubt be very useful but I have already been having
great success with multi-part/form data over http.
The clipboard is the obvious SIMPLE way to go. I want this to work on Windows,
Mac and Linux in that order. I believe they all have an embarrassment of riches
when it comes to use of clipboard. REBOL is lagging here painfully.
I did get Gregg's %winclip partly going today. But alas it turns out image! is
not yet supported by my version of Rebol/Command :-((
<<
** Script Error: Invalid argument: image!
** Where: context
** Near: create-bitmap: make routine! [
>>
He says the new View/Pro does though, so I guess Command will too. But when?
It makes no sense for REBOL to neglect binary clipboard:// copy on the major
graphics operating systems. It just kills a major market for developing REBOL
apps.
./Jason