IMatch 2018 Sneak Peak 1

[Mario]

Progress on IMatch 2018 is steady. Since I plan to do some things never done before in IMatch 2018, scheduling is a bit like tensor math... 

Anyway. I've reached another milestone today, with the completion of a new type of apps: App Views. I've mentioned this new concept here and there in some of my previous posts.

An App View is a normal IMatch app. The difference is that it is not opened in an App panel or a modal window, but as a new View inside IMatch. Similar to the Media & Folders View or the Category View.

A View App has a lot of screen estate to work with, and creates a large space for exciting things to happen.
App Views show up in the IMatch View menu and the user can launch them from there. IMatch remembers open App Views per workspace and reopens them automatically when you load the same workspace again. Neat.

The hardest part was the plumbing in the panels. So far there was always an active file window - but now no more! An App View us no File Window and I had to change all panels to deal with that gracefully. Some panels don't need a file window, so they work as before. Panels which need an active file window just blend out when you switch to an App View. In the screen shot below, the Metadata Panel is unavailable (needs a file window) while the App Manager works normally.

Does not look like much yet, but will (click to zoom):



This new type of View is the stage on which some of the features planned for IMatch 2018 will play.
These features require fairly complex visualization and user interfaces, and HTML5 gives me the best tools to do that. I'll keep you posted.

[jch2103]

Interesting!

[ben]

Great, good to know you are making progress with the next big step.
I followed your hints in previous posts about this new app-view. 

The hardest part was the plumbing in the panels. So far there was always an active file window - but now no more! An App View us no File Window

Now, i am a bit confused.
One argument about not wanting to change the file window too much any more was that this new app view would give more possibilities.
So, i think the app-view should definitely act as a normal file window as well! Or is this planned for the future, which would be fine?

If we get a new way of displaying files, then i would want to work on the files as always, i.e. writing metadata and keywords etc.

Ben

[Mario]

I plan to implement File Window Layout Apps as well. Different purposes for both app types.
I'm my concept works out, an App View can also act (optionally) as a file window - supplying panels with data. But this is optional, not all apps views will need that.

[ben]

Great. Then even better. 
Looking forward to the file window app

[Mario]

Me too.
But File Window Apps are more complicated from the IMatch side as well as from the app side. A File Window app has a lot of freedom but has to supply critical information and data in specific ways - the rest of the system (e.g., panels) rely on that. Since this is yet another thing I never did before (nobody has, probably) I'll have to make this up as I go...

I plan to provide a base JavaScript FileWindow class which custom apps then derive from. This allows us to bundle common code in one place and to use a framework approach for new File Window Apps. Critical. This reduces the amount of code to write and makes things easier.

Critical points I have identified and need to tackle:

+ Handling large data volumes (dealing with a few hundred files is easy, but what if the user selects a drive or even @All)?
+ Message processing App => IMatch
+ Message processing IMatch => App
+ Maintaining the data structure that makes up a File Window (hierarchical groups of files in specific orders)
+ Dealing with the File Window toolbar (which has to be there for all file windows, even if it is only used to switch to another layout). All FWApps to disable/hide things they don't support etc.
+ Handling sort profiles (or not, up to the FWApp)
+ Handling settings or all kinds, persistence, ...
+ ...

Thankfully I have solutions for most of these points already. Been thinking about this for a while.

An App View does not have any of these restrictions or requirements. It's basically a large App window that occupies the entire IMatch window. And then in some way loads, processes and displays data contained in the IMatch database. Or whatever.

Hence the two concepts. I see use for both.

I'm also looking into auto-run apps, which are automatically started by IMatch and kept running in the background (in invisible app windows). This would allow us to write apps which always run, do stuff, react on events etc. There are several obstacles, from security to resource consumption. I will know more about this after I did some experiments.

[ben]

Wow. Now I see why you first work on normal app-views.
Good luck