Prev: > Lookout for KC52 YRY
Next: UKPOST pop3 settings
From: Folderol on 4 Aug 2010 12:26
On Wed, 4 Aug 2010 14:15:31 +0000 (UTC)
Tony Houghton <h(a)realh.co.uk> wrote:

> In <vQr*PjLft(a)news.chiark.greenend.org.uk>,
> Theo Markettos <theom+news(a)chiark.greenend.org.uk> wrote:
>
> > Jim Lesurf <noise(a)audiomisc.co.uk> wrote:
> >> My personal 'magic wish' for ROX would be for it to provide an easy
> >> mechanism for 'save as' dragbox *before* the data to be saved is generated
> >> in the program. One as easy and part-of-ROX-out-of-the-box as the loading
> >> and running side.
> >
> > One idea to do this would be to modify the toolkit(s) (GTK, Qt etc) to
> > generate save as dragboxes rather than mini-filers. Then you'd just need to
> > drop in a new libgtk.so shared library and all GTK apps should use that. It
> > doesn't make the app load things by drag and drop but it gets rid of the
> > 'Save As' mini-filer.
> >
> > The difficulty is that so much in the system depends on a specific version
> > of GTK, so you'd have a job to keep up - you'd probably need to repatch and
> > rebuild at every upgrade.
>
> You could try posting an enhancement request in the bug tracker, asking
> for save dialogs to have a draggable icon. Surely it can't be just (ex)
> RISC OS users who would think it more logical to save a file by dragging
> the file from the application to the filer instead of dragging the
> destination in to the application?
>
> However, I filed a bug report in 2003 to get file choosers to simply
> have the same single-click-to-open option as Nautilus (which even MS
> Windows can manage) and there's still no sign of that actually getting
> implemented in a release, so God knows how they'd cope with something as
> radical as drag & drop.

Someone did write a patch for gtk that provided an integrated drag and
drop for file saving and offered it for inclusion, but was told it
wasn't wanted. My understanding is that it wasn't said as nicely as
that :(

Sadly, I no longer know who it was or where the code was posted :((

--
Will J G
From: Jim Lesurf on 4 Aug 2010 13:23
In article <20100804172658.27f71d5c(a)debian>, Folderol <folderol(a)ukfsn.org>
wrote:


> Someone did write a patch for gtk that provided an integrated drag and
> drop for file saving and offered it for inclusion, but was told it
> wasn't wanted. My understanding is that it wasn't said as nicely as that
> :(

I can understand that not everyone would prefer it - particularly those who
aren't accustomed to finding it handy. :-) For my part I find the save as
trees a real PITA. So I tend to just use ROX to create blank files first.
Personally, I find that quicker that fiddling about with filer trees.

My problem is that I am particularly clueless about Python, and can't make
head or tail of how ROX functions internally. Way beyond my levels of
'programming skill' (sic, in my case. :-) )

However my interest here was just for DandD for ROX. Given the 'everything
is a file' axiom of nix I was wondering if someone cleverer than I could do
in the following way...

To have ROX monitor somewhere a specific file name/location (or pipe, or
stream). The app code then uses something that - to the ROX app - looks
just like a request to open a file

So in C something like fopen(funnyroxname) for 'reading a file' where the
name would 'open a file in the magic ROX 'directory' and its name give a
sign of if it was a file or a new dir and any type info. That then prompts
ROX to go though a savebox routine and put a value back 'into that file'.
The rox app then reads the results of the actual DandD 'from the file' and
the app/user can then tell from this where the 'save file icon' was dropped
and get the destination for a following open and write.

Does that make any sense, or is it just daft? The idea is to leave the
dealing with the DandD to *ROX* and just let the app read the results. But
I realise that it might be impractical for reasons I don't know. Anyway,
the idea is to let ROX do the bits which would be 'common mode' for the
apps using ROX - just like the way AppRun can give you the environment from
which a dropped file's name can be read when the app is run. Then the app
writer only needs a minimal interface in their program in whatever language
or script they use.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

 | 
Pages: 1
Prev: > Lookout for KC52 YRY
Next: UKPOST pop3 settings