Author Topic: Most Recently Opened Document - technical feasibilty / design discussion  (Read 2286 times)

Lars

  • Hero Member
  • *****
  • Thank You
  • -Given: 2
  • -Receive: 78
  • Posts: 835
  • Karma: +25/-0
    • View Profile
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).
« Last Edit: May 04, 2021, 03:05:20 pm by Lars »

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 32
  • Posts: 1000
  • Karma: +21/-0
    • View Profile
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.

Lars

  • Hero Member
  • *****
  • Thank You
  • -Given: 2
  • -Receive: 78
  • Posts: 835
  • Karma: +25/-0
    • View Profile
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.
« Last Edit: May 04, 2021, 03:34:56 pm by Lars »

Andi B.

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 28
  • Posts: 594
  • Karma: +7/-1
    • View Profile
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?

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 32
  • Posts: 1000
  • Karma: +21/-0
    • View Profile
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.

Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 39
  • Posts: 724
  • Karma: +12/-0
    • View Profile
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?

Remy

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 15
  • Posts: 414
  • Karma: +0/-0
    • View Profile
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

andreas

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 1
  • Posts: 36
  • Karma: +3/-0
    • View Profile
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)..
« Last Edit: May 06, 2021, 12:52:40 pm by andreas »

Lars

  • Hero Member
  • *****
  • Thank You
  • -Given: 2
  • -Receive: 78
  • Posts: 835
  • Karma: +25/-0
    • View Profile
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.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 15
  • -Receive: 32
  • Posts: 1000
  • Karma: +21/-0
    • View Profile
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.

andreas

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 1
  • Posts: 36
  • Karma: +3/-0
    • View Profile
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?)

Remy

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 15
  • Posts: 414
  • Karma: +0/-0
    • View Profile
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*
« Last Edit: May 07, 2021, 05:12:27 am by Remy »

Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 39
  • Posts: 724
  • Karma: +12/-0
    • View Profile
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.

Remy

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 15
  • Posts: 414
  • Karma: +0/-0
    • View Profile
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  ;) 

Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 39
  • Posts: 724
  • Karma: +12/-0
    • View Profile
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.