Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dariusz Piatkowski

Pages: 1 2 [3] 4 5 ... 65
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 all ideas merit review, regardless how "crazy" they may feel/ 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.


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.


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.

Hi Andi,

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 - 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).

Applications / Re: Most Recently Opened Documents - Discussion
« on: May 03, 2021, 08:46:32 pm » 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", but let's take this to another thread, please see =>;board=15.0 in Programming section.

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?

Utilities / Re: QT5 Runtime
« on: April 23, 2021, 04:49:22 am »
ivan, Joop,

Head on over to the GitHub HOME for QT5 =>

Scroll down a tad, you have the option to d/l the ZIP files as well.

The Wiki itself (with all the gory details, or the "goodies", it all depends on how you look at it and what in particular you are looking for) is HERE =>

Utilities / Re: QT5 Runtime
« on: April 21, 2021, 07:11:16 pm »
Hi ivan,

'yum list qt5*' will return a whole bunch of RPM packages...I'm sure somewhere in there is the runtime...I haven't looked at them myself quite yet.

Heck, 'yum list qt5*base*' shows the following:

Code: [Select]
[G:\]yum list qt5*base*
Loaded plugins: changelog, downloadonly, ps, replace, verify
Available Packages
qt5-qtbase.i686                           5.13.1-1.oc00              netlabs-rel
qt5-qtbase-common.noarch                  5.13.1-1.oc00              netlabs-rel
qt5-qtbase-debuginfo.i686                 5.13.1-1.oc00              netlabs-rel
qt5-qtbase-devel.i686                     5.13.1-1.oc00              netlabs-rel
qt5-qtbase-examples.i686                  5.13.1-1.oc00              netlabs-rel
qt5-qtbase-gui.i686                       5.13.1-1.oc00              netlabs-rel
qt5-qtbase-private-devel.i686             5.13.1-1.oc00              netlabs-rel
qt5-qtbase-static.i686                    5.13.1-1.oc00              netlabs-rel

Programming / Re: VSQM.H - errror due to comment?
« on: April 21, 2021, 05:39:20 pm »
Heck...further on I find the following:

Code: [Select]
#define IDH_IDMRLSALL   :ç 421

That ":ç" doesn't look right to me...but is that supposed to be some kind of double-byte code character with a special meaning?

Programming / VSQM.H - errror due to comment?
« on: April 21, 2021, 05:35:21 pm »
Looking at this header file and found the following:

Code: [Select]
/*                                                                    */
/* String table IDs                                                   */
/*                                                                    */
#define IDSNAME          10
#define IDSTITLE         20
#define IDSHELP          21    /* Help window title string
#define IDSDTLSTL        30
#define IDSQUEUE1        40

It would appear to me that the "/* Help window title string" has an un-ended comment which actually causes all teh remaining #define's to be commented out as well.

This carries on for about 40 line of code until the following:

Code: [Select]
#define VQBADPRIOSTR     84

#define ID_LISTBOX       90     /* Queues listbox ID

/*                                                                    */
/* Menu IDs                                                           */
/*                                                                    */

...which despite being an un-ended comment is OK since the "/* Queues listbox IS" is followed by multi-line comment anyways which correctly ends the full comment section.

Does anyone know if this is correct? Or is this an un-documented but otherwise intentional exclusion of all these DEFINEs?

Programming / Re: OS2MEDEF.H typedef - what is it?
« on: April 18, 2021, 04:18:14 pm »
OK, thanks Lars!

The last released version of VSLICK is short a couple of user-defined SYMBOLS, and that would allow me to split up all the types of declarations into their separate colour highlights...but still, even with that being the case the four currently available definitions cover a pretty good amount of the overall field.

Programming / OS2MEDEF.H typedef - what is it?
« on: April 17, 2021, 06:45:09 pm »
So there is this declaration in the OS2MEDEF.H header file and I'm having a hard time interpretting it.

Alright, looks like 'FNMCI' is a function, the argument types follow in the parenthesis, but from a tagging perspective (DEFINE vs STRUCT vs TYPEDEF) should this alias be treated as a VARIABLE or a FUNCTION (as I write this I'm actuallying questioning whether this is even the rigth way to put this very question)?

Code: [Select]

I'm asking b/c I'm progressing with my VSLICK OS2 Toolkit tagging project and can't quite figure out where this one belongs.


Programming / Re: VSLICK - OS/2 Toolkit Support Package
« on: April 12, 2021, 08:20:04 pm »
Hi Ibrahim,

Sorry to hijack this thread, but could you point us to where we can find a copy of VSLICK? I've been looking for a good OS/2 based IDE that's no VIM for a while now

I'm afraid there is no official way of obtaining Visual SlickEdit v4.x for OS/2 anymore. That product was available around 1993-1999 timeframe. The last fix/update I have here is Feb_1999.

Having said that, I would not be surprised if you could still find this through sites like eBay or any of the numerous archive sites out there.

Programming / Re: VSLICK - OS/2 Toolkit Support Package
« on: April 08, 2021, 07:51:15 pm »
Hmm, I wasn't quite that deep-diving into the built-in functions, but I suspect this is probably coded in their seeded macros. I will check it out...first I need to actually understand what it does, will do a little readiing on that.

No, not just the tag files. I have done that already, and while it is very functional on it's own, without there being some kind of visual and more sophisticated syntax/keyword highligting it's still somewhat difficult for a coding newbie to understand all the seeded DEFINEs and TYPEDEFs, etc.

So my approach is to combine all of that functionality and put together a fully functioning package where any of the OS/2 Toolkit objects are recognized and appropriately identified. This way you could certainly use something like the tag file functionality to get a super-quick definition of the object itself.

Take a look at the attached capture, and let me use that to point out what I'm trying to do. Heck, it may very well be that other environments can in fact already do that...LOL! Well, I am pretty certain that VAC++ 4.0 can, but that's a fully fledged IDE that comes with some of it's own shortcomings.

OK, so looking at that capture here is what I can readily pick up:
1) the stuff in RED is a seeded Toolkit define

2) the stuff in YELLOW (well, mango maybe?) is a seeded TYPEDEF

3) the stuff in darker blue are all functions
- DosCreateEventSem
- DosAsyncTimer
- DosWaitEventSem...

4) while everything else in light blue is the stuff that's really the custom development, the stuff I (or any previous authors) have created
- ...and all the other variables and code

As a new developer looking at the existing codebase I have absolutely no idea (lack of knowledge and experience with the OS/2 APIs) to know this. But if my IDE can help me out in pointing this out, well, it becomes progressively easier to understand where to look for further info and/or the answers.

For now at least that's the plan.

Programming / VSLICK - OS/2 Toolkit Support Package
« on: April 08, 2021, 03:06:49 am » why feel like a second-class citizen and languish in the "forgotten about" category of Developers???  :o

I have been using Visual SlickEdit for some years now, formerly professionally, and having had great experience with it I had actually purchased the official software way back in the day when it was still available.

So fast forward to today and as I'm trying to do a bit more in support of our platform, and therefore spending a LOT more time on reading either existing code, or trying out new things, I realized that by all accounts we are sort of stuck even in terms of the look'n'feel of the tools we use (regardless of just how old these very tools themselves are).

But...VSLICK is incredibly customizable...I mean just about everything in there is. No, I'm not trying to sell you on it (heck, there is nothing to buy out there), but the ability to re-configure things also means that we have a way to bring a little bit of that modern look'n'feel to our platform, and by extension I hope it may be easier for anyone new to developing on our platform to actually give things a try.

As such, I have been crazily busy trying to assemble a decent 'OS/2 Toolkit Support Package' for VSLICK.

What I mean by that is the following:
1) modern theme
2) syntax highlighting
3) recognition of the native OS/2 Toolkit declarations (DEFINEs, TYPEDEFs, STRUCTs, etc.)
4) pre-built 'Project Definition' modules that allow you to build projects using any C/C++ environments you may be using

Attached screenshot is what my DISKIO source looks like now..heck of a lot easier to read then with the default and/or no syntax highlighting, or no OS/2 Toolkit recognition.

So far I have covered the following Toolkit header files:
1) OS2.H
4) BSE.H
10) PM.H
14) PMWP.H

There are a pile more, I haven't touched on any of the networking stuff yet. I think hitting the ol' OS2EMX.H is probably a must, even if that is needed just to simplify reading any existing code base.

Beyond what I have I'm looking for recommendations as to what else I need to prioritize? Which header files should I go through before we have something that feels like it covers most of the stuff one might normally use?

Pages: 1 2 [3] 4 5 ... 65