OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Dariusz Piatkowski on May 02, 2021, 10:14:22 pm

Title: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Dariusz Piatkowski on May 02, 2021, 10:14:22 pm
Hi Martin,

Can't help you with the questions you posed, but I'd like to piggy back off of the topic you started and ask the following question: what WPS class would need to be extended/replaced in order to create a "Most Recently Opened Documents" object which literally shows a list of documents (should have a user adjustable setting to control how many are shown) there were most recently opened.

In short, I wish there was an easy way to re-open the same doc I had just looked at, withouth me having to go off fishing for it once again.

I suppose this would be a Folder like object, but it really would not have any persistent objects (the previously opened Documents) present there, instead maybe shadows could represent each one?

Title: Re: Most Recently Opened Documents - Discussion
Post by: Martin Iturbide on May 02, 2021, 10:22:39 pm
what WPS class would need to be extended/replaced in order to create a "Most Recently Opened Documents" object which literally shows a list of documents (should have a user adjustable setting to control how many are shown) there were most recently opened.
...that's a good question.  ;D

Regards
Title: Re: Most Recently Opened Documents - Discussion
Post by: Lars on May 03, 2021, 02:55:08 pm
what WPS class would need to be extended/replaced in order to create a "Most Recently Opened Documents" object which literally shows a list of documents (should have a user adjustable setting to control how many are shown) there were most recently opened.
...that's a good question.  ;D

Regards
It would most likely not be derived from WPFolder because that would mean that You'd need a REAL folder called "Most recently used documents" or so which you surely do not want to have. But maybe WPFileSystem. That is abstract as it cannot neither create a real folder not a real file.
But likely the best would be WPAbstract. A class derived from WPAbstract can save stuff in OS2.INI as a default, transparently as object properties, without writing new code.
It can create any view it deems appropriate, including a frame window with a container (listing all those most recently used files).
Title: Re: Most Recently Opened Documents - Discussion
Post by: Andreas Schnellbacher on May 03, 2021, 07:55:26 pm
[Most Recently Opened Documents]

Dariusz, the problem is not the WPS object, but the functionality.

in Windows, all apps write to the same huge registry. There exists the 'Recent File List' key that is used by many applications. I'm happy that in OS/2, all applications usually use their own ini file. But there's also no standardized way to save the recent files. Some even use text ini files. (Additionally, some apps have multiple file lists for different purposes). But to allow for such a system function, all applications must implement history or recent file lists first and the system has to know where these apps store it and how.

Even if you consider to include only apps with that feature, you have to know where the apps store this and how. The ini files could be found still easily, but the relevant ini apps and keys are app-dependent. So, no chance without a huge list with that information.

Start first with having such a feature implemented for the apps you regulary use.
Title: Re: Most Recently Opened Documents - Discussion
Post by: Andi B. on May 03, 2021, 08:04:43 pm
Thinking loud - would be intercepting DosFileClose with compare of 'known' extensions and 'last write' compare an option? Of course couldn't be done in wps context but on file system driver level?
Title: Re: Most Recently Opened Documents - Discussion
Post by: Andreas Schnellbacher on May 03, 2021, 08:16:35 pm
DosFileClose with compare of 'known' extensions and 'last write' compare
Interesting, but not all opened files are loaded into an app. Apps usually open many other files that are closed - either by the app or by the system on closing the app. And files can be opened and closed with the libc functions.

I suppose, without implementing this into an app, there won't be a chance.
Title: Re: Most Recently Opened Documents - Discussion
Post by: Lars on May 03, 2021, 08:24:05 pm
"most recent files" is a global function. I don't see any point in making that "per application". But maybe I am lacking some phantasy.
Screwing around on file system driver level is counterproductive and completely superfluous. There already exist WPS functions that can tell you which file objects are currently active/open and there are notifications when files are changed on a file system level. Taking all that is sufficient to come up with a "most recent files" WPS class.  And if you go for only the last 20 files, then writing this info to OS2.INI is also acceptable in my point of view.
I love reusing code, I hate writing own code.
Writing your own code means testing which typically takes far more time then writing it.
Title: Re: Most Recently Opened Documents - Discussion
Post by: Dariusz Piatkowski on May 03, 2021, 08:46:32 pm
Ahh...you guys, I think I will take that conversation to another thread, I feel bad I hi-jacked Martin's post!

High level though, my thinking is as follows:

1) Intercept any application 'Open File' action at the OS level (so literally having some kind of a daemon that watches to see what files are being opened)
- user settings would possible filter this down to only a certain sub-set of applications
- this daemon would keep track the "most recently x opened" files, as per the user's settings

2) Show the user a dynamically maintained list, where one would simply interact with the object using the default system behavious (so rely on Associations, etc.)
- the "container" object that would allow the user to select such a file would be either a purposely built own class object, or perhaps a folder where the objects themselves would be represented as SHADOWs - idea being to re-use as much of the underlying OS structure, and therefore functionality, as possible

My goal was very similiar to what Lars' thinking is: use as little NEW code as possible, rely on existing platform / OS infrastructure to handle much of the lifting.

Thus my original question: what would be best suited to serve as that "container object"? In parallel to that, what are the current APIs that I could use to monitor the current files that are opened?

Andi, maybe as you suggested that intercepting DosFileClose would allow me to build that dynamic list of files that have been opened...that list would continue to be purned as per user settings and filters, which in theory should give us a workable solution.

Use Case
======
Let's say I only care about PDF files. I have them all over the place, my NAS box in particular...and I just do not feel like going through the full directory/path navigation each and every time I need to open one up. This to me is very real you guys...I moved our documents from the OS/2 box onto the NAS some tiem ago, we now have a single centralized DOC repo for the full house...but that requires me to do a hell of a lot more mouse clicking to just get to the file I want! lol

Anyways, Martin, I'm sorry...your post TITLE was precisely what I had in mind for some time now and the ideas just needed to "come out"...lol, but let's take this to another thread, please see => https://www.os2world.com/forum/index.php?action=post;board=15.0 (https://www.os2world.com/forum/index.php?action=post;board=15.0) in Programming section.
Title: Re: Most Recently Opened Documents - Discussion
Post by: Andreas Schnellbacher on May 03, 2021, 09:00:59 pm
"most recent files" is a global function.
Do apps use that WPS function? (I assume that's also the one been used for reopening file objects on opening work area folders, which doesn't work for all apps.)
Title: Re: Most Recently Opened Documents - Discussion
Post by: Martin Iturbide on May 04, 2021, 01:26:36 am
Hi

I slip the topic  !!

Regards
Title: Re: Most Recently Opened Documents - Discussion
Post by: Martin Iturbide on May 04, 2021, 01:27:41 am
oops. I'm merging you post here.

Alright, this discussion is moved from the thread Martin started in the Application Forum: Desktop Enhancements for WPS.

My idea is: create a "Most Recently Opened Documents" object which literally shows a list of documents (should have a user adjustable setting to control how many are shown) there were most recently opened.
This should provide an easy way to re-open the same doc I had just looked at, withouth me having to go looking for it once again.

I suppose this could be a Folder like object, but it really would not have any persistent objects (the previously opened Documents) present there, instead maybe shadows could represent each one?

High level though, my thinking is as follows:

1) Intercept any application 'Open File' action at the OS level (so literally having some kind of a daemon that watches to see what files are being opened)
- user settings would possible filter this down to only a certain sub-set of applications
- this daemon would keep track the "most recently x opened" files, as per the user's settings

2) Show the user a dynamically maintained list, where one would simply interact with the object using the default system behavious (so rely on Associations, etc.)
- the "container" object that would allow the user to select such a file would be either a purposely built own class object, or perhaps a folder where the objects themselves would be represented as SHADOWs - idea being to re-use as much of the underlying OS structure, and therefore functionality, as possible

My goal was very similiar to what Lars' thinking is: use as little NEW code as possible, rely on existing platform / OS infrastructure to handle much of the lifting.

Thus my original question: what would be best suited to serve as that "container object"? In parallel to that, what are the current APIs that I could use to monitor the current files that are opened?

Andi, maybe as you suggested that intercepting DosFileClose would allow me to build that dynamic list of files that have been opened...that list would continue to be purned as per user settings and filters, which in theory should give us a workable solution.

Use Case
======
Let's say I only care about PDF files. I have them all over the place, my NAS box in particular...and I just do not feel like going through the full directory/path navigation each and every time I need to open one up. This to me is very real you guys...I moved our documents from the OS/2 box onto the NAS some tiem ago, we now have a single centralized DOC repo for the full house...but that requires me to do a hell of a lot more mouse clicking to just get to the file I want! lol
Title: Re: Most Recently Opened Documents - Discussion
Post by: Lars on May 04, 2021, 09:12:10 am
"most recent files" is a global function.
Do apps use that WPS function? (I assume that's also the one been used for reopening file objects on opening work area folders, which doesn't work for all apps.)
My understanding of that function is a collection of any files that were open on the desktop.These should be recallable and presented in a container where they can be double clicked and the default WPS action invoked on them.
For many apps that need it, an application specific list already exist. I see no need to duplicate that.
The user would invoke that function, not an application.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Andi B. on May 04, 2021, 09:47:34 am
Quote
"most recent files" is a global function. I don't see any point in making that "per application".

Agree.

Quote
Screwing around on file system driver level is counterproductive and completely superfluous.
IMHO dangerous. And maybe a performance disaster. I wouldn't risk to try it out by myself.

Quote
There already exist WPS functions that can tell you which file objects are currently active/open and there are notifications when files are changed on a file system level.
Sounds like a very elegant way. But does this also work when you f.i. open a file from cmd line in an editor which writes this file afterwards. And do you get notifications when you f.i. open a pdf by double clicking in the email client which fires up qpdfview and when do 'Save as' in qpdfview?
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Andreas Schnellbacher on May 04, 2021, 10:20:08 am
Sounds like a very elegant way. But does this also work when you f.i. open a file from cmd line in an editor which writes this file afterwards. And do you get notifications when you f.i. open a pdf by double clicking in the email client which fires up qpdfview and when do 'Save as' in qpdfview?
... plus files opened via file dialog.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Dariusz Piatkowski on May 04, 2021, 01:59:15 pm
Hi Andi,

...
Quote
There already exist WPS functions that can tell you which file objects are currently active/open and there are notifications when files are changed on a file system level.
Sounds like a very elegant way. But does this also work when you f.i. open a file from cmd line in an editor which writes this file afterwards. And do you get notifications when you f.i. open a pdf by double clicking in the email client which fires up qpdfview and when do 'Save as' in qpdfview?

Hmm, I cannot see being able to get that to work reliably, here is why: those types of "Open" events typically place the actual PDF file in temp storage, so stuff is pulled out of email body/ZIP file/whatever, tossed into temp and then the default application is evoked. The problem with making this work reliably is that the temp storage may not be persistent...heck, all my TMP/TEMP settings point to a RAM drive...fast - sure, clean - sure b/c a re-boot completely wipes it clean for me.

But this could be turned into a setting that the user activates (meaning, s/he decides that YES indeed, they do want those kind of openning events tracked and listed in the MROD dynamic list).
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Lars on May 04, 2021, 03:02:55 pm
Quote
"most recent files" is a global function. I don't see any point in making that "per application".

Agree.

Quote
Screwing around on file system driver level is counterproductive and completely superfluous.
IMHO dangerous. And maybe a performance disaster. I wouldn't risk to try it out by myself.

Quote
There already exist WPS functions that can tell you which file objects are currently active/open and there are notifications when files are changed on a file system level.
Sounds like a very elegant way. But does this also work when you f.i. open a file from cmd line in an editor which writes this file afterwards. And do you get notifications when you f.i. open a pdf by double clicking in the email client which fires up qpdfview and when do 'Save as' in qpdfview?

No, it would only work for files opened via the WPS, but see last paragraph. But that's exactly the question: what are the REAL expectations ? If you use an app to open files and that app already has support for "most recently used docs" then there is no need to offer that via the WPS.

The WPS knows nothing about applications. But it can detect that files were being modified on file system level (I don't know if this is limited to file content or also for changing EAs).
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Dariusz Piatkowski on May 04, 2021, 03:21:26 pm
Lars,

...
No, it would only work for files opened via the WPS, but see last paragraph. But that's exactly the question: what are the REAL expectations ? If you use an app to open files and that app already has support for "most recently used docs" then there is no need to offer that via the WPS.

The WPS knows nothing about applications. But it can detect that files were being modified on file system level (I don't know if this is limited to file content or also for changing EAs).

For me it's the WHOLE thing...meaning: the utility should have visibility to ALL WPS file "Open/Close" events, the key stipulation here is WPS, b/c in my mind that would allow us to utilize as much of the currently existing OS API support as possible.

This approach is the core function of the utility: avoid having to navigate through multiple paths to re-open a document. While most of us may think of this as storage volume navigation (so drive paths, etc.), one should also consider the user-interface pathway to the application itself as well. In other words, why force me to navigate all of my Program Menus just to 1st open the right application so that I can then select the file I'm interested in?

I want it all done with "one click" instead! Should I want to open that particular file with an alternate application (so back to my use-case of PDF files: that could be GSView, or Lucide or QPDFView) I would then have the WPS provided option of selecting that alternate application. This is part of the reason why I was starting to think of it as a folder object where the files themselves could be listed as shadows...thus preserving all of the existing WPS functionality that readily applies to dealing with such objects.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Lars on May 04, 2021, 03:27:04 pm
Actually, there exists an API on file system level that happens to be only documented in the DDK, here it is (discussion found in some forum):

Code: [Select]
[later] After perusing \ddk\h (A great place find
"undocumented" os/2 APIs), it appears that you may the
correct -- the DosFindNotify...() apis no long exist as
32bit apis (but you can still import the 16bit ones if if
like).

They appear to have been replaced by something better
(which probably uses the FindNotify IFS services
underneath). You'll have to figure these out on your own
(please report back here);but they don't look too hard:

#pragma pack(1)

typedef struct _CNPATH { /* CHANGENOTIFYPATH */
ULONG oNextEntryOffset;
ULONG wFlags;
USHORT cbName;
CHAR szName[1];
} CNPATH;
typedef CNPATH *PCNPATH;

typedef struct _CNINFO { /* CHANGENOTIFYINFO */
ULONG oNextEntryOffset;
CHAR bAction;
USHORT cbName;
CHAR szName[1];
} CNINFO;
typedef CNINFO *PCNINFO;

#pragma pack()

// Equates for ChangeNotifyInfo baction field

#define RCNF_FILE_ADDED 0x0001
#define RCNF_FILE_DELETED 0x0002
#define RCNF_DIR_ADDED 0x0003
#define RCNF_DIR_DELETED 0x0004
#define RCNF_MOVED_IN 0x0005
#define RCNF_MOVED_OUT 0x0006
#define RCNF_CHANGED 0x0007
#define RCNF_OLDNAME 0x0008
#define RCNF_NEWNAME 0x0009
#define RCNF_DEVICE_ATTACHED 0x000A
#define RCNF_DEVICE_DETACHED 0x000B

APIRET APIENTRY DosOpenChangeNotify(PCNPATH PathBuf,
ULONG LogSize,
PHDIR hdir,
ULONG ulReserved);

APIRET APIENTRY DosResetChangeNotify(PCNINFO LogBuf,
ULONG BufferSize,
PULONG LogCount,
HDIR hdir);

APIRET APIENTRY DosCloseChangeNotify(HDIR hdir);

As you can see, changes to files are logged and can be queried. But you will have to specify a set of paths to look for. I don't know if directories are supported recursively.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Andi B. on May 04, 2021, 03:58:06 pm
Quote
This approach is the core function of the utility: avoid having to navigate through multiple paths to re-open a document. While most of us may think of this as storage volume navigation (so drive paths, etc.), one should also consider the user-interface pathway to the application itself as well. In other words, why force me to navigate all of my Program Menus just to 1st open the right application so that I can then select the file I'm interested in?

The WPS way of work was always different than the Win way. You shouldn't navigate through program folders but open your document folder or even more advanced one of your work areas. If you don't like to open your pdf with the standard program you only have to right click and select the other programs from the open with popup menu. 

If you set your document folder sort option to last modified and always maintain sort order than you're nearly done. No clue if this sorting also works with shadows of documents in other folders / work areas.

The programs own history are necessary for other OSes which aren't designed like the WPS (document centric) but build around programs. Maybe also we OS/2 users forgot a bit the WPS philosophy cause we are also have to use the program centric model of other OSes?
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Dariusz Piatkowski on May 04, 2021, 05:13:57 pm
Andi,

The WPS way of work was always different than the Win way. You shouldn't navigate through program folders but open your document folder or even more advanced one of your work areas. If you don't like to open your pdf with the standard program you only have to right click and select the other programs from the open with popup menu...

OK, but that ONLY works assuming the actual storage media filesystem supports all the OS/2 WPS functionality AND you have your documents centrally located. Great point, but even on a native OS/2 install how likely are you to have all of your documents in a single folder? Yes, I am oversimplifying a bit, but the point is that even if you had a central Documents folder where all the other documents were stored in sub-folders, you'd still need to navigate down to them. And I certainly do not want to toss Gigs of docs into a 'Working Folder'.

...The programs own history are necessary for other OSes which aren't designed like the WPS (document centric) but build around programs. Maybe also we OS/2 users forgot a bit the WPS philosophy cause we are also have to use the program centric model of other OSes?

Yes, I think I agree with most of your stipulation here. I have always found OS/2's way of dealing with docs as an object far superior to anything else out there. Still, there is an element of convenience (always will) in being able to re-open an app specific file from within that ap.

However, I would say that the challenge here isn't so much brought on by forgetting about WPS philosophy, rather it is driven by the recognition of the changing storage device landscape. As I previously mentioned, my OS/2 box is no longer the central doc repo, that stuff has moved on to the NAS box, which does not even support EAs.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Andreas Schnellbacher on May 05, 2021, 03:18:53 am
As you can see, changes to files are logged and can be queried. But you will have to specify a set of paths to look for. I don't know if directories are supported recursively.
Yes, interesting. But the cited notify actions seem to handle only changes of files or dirs in a folder. I don't see anything that can be used to track opened files. Am I wrong?
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Remy on May 06, 2021, 12:42:46 am
As you can see, changes to files are logged and can be queried. But you will have to specify a set of paths to look for. I don't know if directories are supported recursively.
Yes, interesting. But the cited notify actions seem to handle only changes of files or dirs in a folder. I don't see anything that can be used to track opened files. Am I wrong?

May be you can have a look on :
Lsof (List Open Files)
https://ecsoft2.org/lsof-list-open-files

I just did a try, and could find opened pdf, odt, txt ...  (pmview open files aren't listed but it has an integrated recall option)
May be use a very simple daemon, extract entries according a list of file type and add/update WPS object under a "Recently opened file" folder with the correct full path name, file extension having the correct associated extension, it should open when click on it. 

RD
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: andreas on May 06, 2021, 12:47:10 pm
i'm not a programmer. and maybe my idea is stupid.
but maybe it's possible to create a folder that automatically collects shadows of every opened document (maybe just some types of documents - recogniced by the data-type or -ending, like *.txt).
additionally you'd need a routine to automatically delete the older shadows.
not sure if that is possible though..

at least it would be nice to have an option for each file or folder to create a shadow into a certain folder with one click (manually)..
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Lars on May 06, 2021, 01:52:22 pm
As you can see, changes to files are logged and can be queried. But you will have to specify a set of paths to look for. I don't know if directories are supported recursively.
Yes, interesting. But the cited notify actions seem to handle only changes of files or dirs in a folder. I don't see anything that can be used to track opened files. Am I wrong?

May be you can have a look on :
Lsof (List Open Files)
https://ecsoft2.org/lsof-list-open-files

I just did a try, and could find opened pdf, odt, txt ...  (pmview open files aren't listed but it has an integrated recall option)
May be use a very simple daemon, extract entries according a list of file type and add/update WPS object under a "Recently opened file" folder with the correct full path name, file extension having the correct associated extension, it should open when click on it. 

RD

This tool does something completely different from what we are talking about. LSOF lists all file (handles) that are currently open by all currently executing processes. This even includes device handles. Not what we want.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Dariusz Piatkowski on May 06, 2021, 02:14:54 pm
Hi andreas,

i'm not a programmer. and maybe my idea is stupid.
but maybe it's possible to create a folder that automatically collects shadows of every opened document (maybe just some types of documents - recogniced by the data-type or -ending, like *.txt).
additionally you'd need a routine to automatically delete the older shadows.
not sure if that is possible though..

at least it would be nice to have an option for each file or folder to create a shadow into a certain folder with one click (manually)..

No, not a stupid idea...there are none like that in my book, and besides, this is a "thinking" session discussion...so all ideas merit review, regardless how "crazy" they may feel/sound...no worries!  8)

What you are suggesting is probably 90% of what I was envisioning as I started to think about this. This is why I had originally talked about it from the perspective of defining an object class which could have it's functionality extended. I thought of the Folder approach as well, and as you pointed out, of using WPS shadows to represent the MROD objects themselves.

I probably need to spend time with the WPS docs to understand how big of a challenge it may be to either extend the existing Folder class, or to flat out define a new 'MROD Folder' which only does this single thing. Either way, I would expect that we should be able to use object inheritance to pick up all WPS functionality currently avaialable for regular WPS folders and use that in our MROD Folder object. As such, things like shadows, being able to open with alternative applications, etc. would all work by default.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: andreas on May 06, 2021, 04:32:50 pm
thanks for your kind response.
i just wonder if it's possible to create a log-file for all opened or pre-defined opened filed.
aen't there any tracking programs already available that might be used for that?
if you have this you'd "just" need to find a routine to create shadows into a specific folder, something like "create shadow *.lwp X:\history" (maybe something like that already exists?)
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Remy on May 06, 2021, 04:48:43 pm
Hi andreas,

i'm not a programmer. and maybe my idea is stupid.
but maybe it's possible to create a folder that automatically collects shadows of every opened document (maybe just some types of documents - recogniced by the data-type or -ending, like *.txt).
additionally you'd need a routine to automatically delete the older shadows.
not sure if that is possible though..

at least it would be nice to have an option for each file or folder to create a shadow into a certain folder with one click (manually)..

No, not a stupid idea...there are none like that in my book, and besides, this is a "thinking" session discussion...so all ideas merit review, regardless how "crazy" they may feel/sound...no worries!  8)

What you are suggesting is probably 90% of what I was envisioning as I started to think about this. This is why I had originally talked about it from the perspective of defining an object class which could have it's functionality extended. I thought of the Folder approach as well, and as you pointed out, of using WPS shadows to represent the MROD objects themselves.

I probably need to spend time with the WPS docs to understand how big of a challenge it may be to either extend the existing Folder class, or to flat out define a new 'MROD Folder' which only does this single thing. Either way, I would expect that we should be able to use object inheritance to pick up all WPS functionality currently avaialable for regular WPS folders and use that in our MROD Folder object. As such, things like shadows, being able to open with alternative applications, etc. would all work by default.

* a REXX which is not a WPS integrated function *
I jus did a test using a rexx daemon "instlof.cmd" (using lsof and scan each seconds - customizable) which creates a Last Opened Folder and it puts into it files (according ext type) when openning a file (e.g. pdf, doc, odt, inf...)
*Warning* the rexx code is very basic, I didn't add any error handling etc..., just for test with some adjustable parameters into it. If you would continue or update the code, you are free to do it. If you give it a try, it is at your own risk :D .
(I've included lsof.zip from hobbes)

May be it could help as an idea for real WPS implementation     

*attachement removed*
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Andreas Schnellbacher on May 06, 2021, 06:16:28 pm
Sorry Remy, that won't help anything in our case, as Lars has already written.

The important info is which app has opened which file.

IMO, that some sort of notification might exist (without an expensive daemon), shows the work area feature of a WPS folder. Unfortunately it works not with all apps, but e.g. with IBM's E.EXE or Aaron's AE.EXE. I don't have an idea why. Of course it also can't work for non-WPS actions, as e.g. when using the file dialog.

And even if we would find out how that works, we're still missing a list of (multiple) last opened files per app: If the work area folder feature is related, it would just give the current ones per folder, not multiple ones per app.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Remy on May 06, 2021, 06:41:12 pm
Sorry Remy, that won't help anything in our case, as Lars has already written.

The important info is which app has opened which file.

IMO, that some sort of notification might exist (without an expensive daemon), shows the work area feature of a WPS folder. Unfortunately it works not with all apps, but e.g. with IBM's E.EXE or Aaron's AE.EXE. I don't have an idea why. Of course it also can't work for non-WPS actions, as e.g. when using the file dialog.

And even if we would find out how that works, we're still missing a list of (multiple) last opened files per app: If the work area folder feature is related, it would just give the current ones per folder, not multiple ones per app.

lsof provides app name which opens the file but of course, it isn't the current topic which is for a WPS improvement.
It was only to show that some options (group opening docs shadows under a same folder) could be achieved...

Hope you could find howto under WPS  ;) 
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Andreas Schnellbacher on May 07, 2021, 05:24:35 pm
lsof provides app name which opens the file but of course,
It displays a list of which process holds which file or device open (locked). (Open files usually can't be e.g. renamed.)

I've written 'has opened', which means 'has loaded'. It's something like hatch-marked file objects to show the load state. A viewer usually opens a file to display it and then closes it. When being opened (loaded) by the WPS, such a file object is usually hatch-marked, provided the viewer is started synchronously. Unfortunately later PDF viewers for OS/2 keep a loaded file either opened or locked. But e.g. Iconedit or PMView do it correctly.

You can try it with e.g. opening a bitmap file object per double click or context menu. In both cases the file object gets hatch-marked, but also can be renamed after that.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Doug Clark on May 09, 2021, 12:23:25 am
I think you might be able to make a modified program object which would copy the file name used when opening  a program to a central "recently opened" list.  The fully qualified file name should be sufficient since the file type would link it to the application. It would probably work with files dropped on the program object, specified as a argument on the Program page, or when double clicking on a file in a folder.  That wouldn't be that difficult to do.  The problem is it would only work when using the WPS to open an app - meaning it would not pick up files opened from the File menu inside the app.  It probably would also not pick up files dropped on an already open application window (as opposed to files dropped on the Program object).

I did a little of this as a way of making long file names work with Win-OS2 apps.  You can make it work when going through the WPS but not when going through the app itself unless you have a way of hooking into the File open feature of an application.  You MIGHT be able to do that if you provided a modified File Open dialog (such as FOC) that would copy the file(s) specified to the central list.

After thinking a minute more - instead of copying the file name to a "central list" what should happen is a shadow is created of the file in a ROD folder.  That way if the file is renamed or moved the "list" would still be accurate due to the magic of the WPS and shadows.

Listing the recently opened docs would then be simply opening the folder containing the shadows - and double clicking on the shadow would start the app.

I don't know if you can make shadows of file system objects stored on media that doesn't support EAs.  If the shadow is stored in OS2.INI then you probably can.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Andreas Schnellbacher on May 09, 2021, 01:05:58 am
I think you might be able to make a modified program object which would copy the file name used when opening  a program to a central "recently opened" list.
Yes, that might work.

It would probably work with files dropped on the program object, specified as a argument on the Program page, or when double clicking on a file in a folder. That wouldn't be that difficult to do.
Yes, both are WPS actions.

The problem is it would only work when using the WPS to open an app - meaning it would not pick up files opened from the File menu inside the app.  It probably would also not pick up files dropped on an already open application window (as opposed to files dropped on the Program object).
Yes, both are PM actions.
Title: Re: Most Recently Opened Document - technical feasibilty / design discussion
Post by: Dariusz Piatkowski on May 09, 2021, 02:35:31 am
Hi Doug,

...I don't know if you can make shadows of file system objects stored on media that doesn't support EAs.  If the shadow is stored in OS2.INI then you probably can.

Yes, this works. I have the "Documents" directory off of my NAS showing on my OS/2 Desktop as a Shadow object. As long as I connect successfully to the NAS (which is done during boot through NetDrive) that object will be 'live' by the time WPS comes up.

Your idea on how to use the WPS Shadow functionality is precisely what I wanted to do.