Process windows tied to workspaces

[Niall Saunders]

Hi Juan, this isn't really a 'bug' in as much as it is a 'wish' . . .

Now that I am 'floating' off key process windows (such as Statistics, Histo and STF to my RHS auxilliary screen, and the console window off to my LHS auxilliary screen) it is somewhat 'strange' to change workspaces only to find that none of the process windows are visible any more.

Sure, if you return to the original workspace, they are all where you left them - so that isn't a problem.

It is just annoying to have to, for example, re-open STF each time you select a new Workspace.

My current 'workaround' is to 'send' the entire contents of the workspace I have been working on, 'to' the next available free Workspace - keeping Workspace 01 for my 'work in progress' (my current PI environment has WS01 = 'live', WS02 = 'Lu', WS03 = 'Rd', WS04 = 'Gn', WS05 = 'Bu', etc. - you see my methodology)

Also, I now have to keep a 'second' instance of PI permanently 'open' - as this remains the ONLY way available to me for opening 32-bit Float FITS, for conversion to 16-bit Unsigned Integer (the 'wireless keyboard' bug, as you have described it, remains - yet I still cannot see how this is a bug 'outwith' the PI code system)

Can you remind us of what data or objects are 'interchangable' between instances of PI? I thought that I remembered you saying that multiple instances of PI would all be fully aware of their brethren, suggesting that inter-instance drag-and-drop might even be a possibility?

Cheers,

[Juan Conejero]

Hi Niall,

This problem could be solved adding a new property to top-level windows: Stay on all workspaces. In this way you'd decide which tools must be attached to a single workspace, and which tools must be present on all workspaces. There would be an additional button on the window's title bar to enable/disable this property, and the core application would remember these settings for all tools across sessions.

What do you think about this approach?

[Juan Conejero]

the 'wireless keyboard' bug, as you have described it, remains - yet I still cannot see how this is a bug 'outwith' the PI code system

I must say that this is perhaps the most magical thing I've seen in my development career. I really can't figure out what can be causing this problem with your keyboard. I've seen weird things happen as a result of faulty wireless peripherals, but nothing like this.

I may be asking you to invite me to a TeamViewer session in the near future, to investigate this directly on your machine. I'd need to build a special version to generate a complete log of all keyboard events.

[Niall Saunders]

Juan - let me first get a 'wired' keyboard connected to the machine. That way I can eliminate/prove the difference between keyboards.

The crazy thing is that I see (or I remember seeing) the same unusual behaviour when I tried running PI over TeamViewer myself !!

I also have a second wireless keyboard (somewhere !!), and I could also try that.

In the meantime, I will be away from my PC for a few days (everyone breathes a sigh of relief !!), so we may have to hold things until I get back.

Cheers,

[bitli]

I vote for the possibility to have processes tied to 'all' workspaces as an option (and naturally this should be remembered  ).

-- bitli

[Carlos Milovic]

I'm in favor of independent workspaces. After all, if I want to change the workspace, is to have a clean space to work in other things, not to bring along all the opened processes, icons, etc. It is just like changing desktops in a linux distro. You don't want that Firefox comes along too. I use one for mailing, other for browsing, one for PI, and the other for text editors... Each one "isolated". Well, I expect the same for PI Just my 2 cents.

[RBA]

This problem could be solved adding a new property to top-level windows: Stay on all workspaces.

I vote yes. This way, everyone's happy and can customize their workspaces as they like.