11 comments
Comment actions Permalink

Hi Chris,

Interesting the way you've approached workspaces. It seems you've given
the ability (by default) to combine your workspaces. One thing about
this, though, is that if I open two workspaces that have a file in
common, then close one workspace, the common file is removed from the
editor. So, the editor now won't contain all the files in the workspace
that remains open. Don't we want the closing workspace to leave open
files that are part of other open workspaces?

Thanks,
Jon

Chris Bartley wrote:

Workspaces 0.6.1 is available at:

http://www.intellij.org/twiki/bin/view/Main/WorkspacesPlugin

Changes since version 0.6:

  • Fixed to work with IDEA Build 650's Open API. Will not work with previous

versions.


0
Comment actions Permalink

Yeah, i think you're exactly right (and it should be pretty trivial to
implement). I'll add it to the To Do list on the Wiki (feel free to add
other ideas to the Feature Requests section).

Thanks!

chris

"Jon Steelman" <steelman@mindspring.com> wrote in message
news:an2anj$d3b$1@is.intellij.net...

Hi Chris,

>

Interesting the way you've approached workspaces. It seems you've given
the ability (by default) to combine your workspaces. One thing about
this, though, is that if I open two workspaces that have a file in
common, then close one workspace, the common file is removed from the
editor. So, the editor now won't contain all the files in the workspace
that remains open. Don't we want the closing workspace to leave open
files that are part of other open workspaces?



0
Comment actions Permalink

I've been thinking more about this, and am not sure how to handle a few
cases. First, assume i have the following:

  • Workspace Foo contains files A and B

  • Workspace Bar contains files B and C

  • Workspace Baz contains files C and D


PROBLEM 1:
If I open Foo and Baz, then files A, B, C, and D will be open. The
Workspaces menu will have checks next to Foo, Bar, and Baz. If i select the
Bar workspace in the Workspaces menu to close it, but files belonging to
other open workspaces aren't closed, then nothing will happen, and there's
no way to close the Bar workspace via the menu.

PROBLEM 2:
If I open Foo and Baz, then files A, B, C, and D will be open. The
Workspaces menu will have checks next to Foo, Bar, and Baz. If i select the
Foo workspace in the Workspaces menu to close it, then only file A will be
closed because it doesn't belong to any other open workspace. B won't be
closed because it belongs to Bar and Bar was deemed "open" since all its
files were open.

There are other similar scenarios, but i guess they all at least partly stem
from how i'm currently determining whether a workspace is open. Right now,
a workspace is open if all its files are open, regardless of HOW they were
opened (e.g. via selecting the item in the Workspaces menu, opening the
file(s) by double-clicking in the project/source/classpath pane,
CTRL-N/CTRL-SHIFT-N, etc.)

I could probably change things around so that a workspace is only considered
open if you explicitly select it to be open via the Workspaces menu, but i'm
so far undecided whether that's more beneficial/intuitive.

Thoughts?

thanks,

chris

"Jon Steelman" <steelman@mindspring.com> wrote in message
news:an2anj$d3b$1@is.intellij.net...

Hi Chris,

>

Interesting the way you've approached workspaces. It seems you've given
the ability (by default) to combine your workspaces. One thing about
this, though, is that if I open two workspaces that have a file in
common, then close one workspace, the common file is removed from the
editor. So, the editor now won't contain all the files in the workspace
that remains open. Don't we want the closing workspace to leave open
files that are part of other open workspaces?

>

Thanks,
Jon



0
Comment actions Permalink

Chris Bartley wrote:

I've been thinking more about this, and am not sure how to handle a few
cases. First, assume i have the following:

  • Workspace Foo contains files A and B

  • Workspace Bar contains files B and C

  • Workspace Baz contains files C and D


PROBLEM 1:
If I open Foo and Baz, then files A, B, C, and D will be open. The
Workspaces menu will have checks next to Foo, Bar, and Baz.


Why would Bar have a check next to it? Seems like only Foo & Baz should
have a check even if all the Bar files happen to be open in the editor.

If i select the
Bar workspace in the Workspaces menu to close it, but files belonging to
other open workspaces aren't closed, then nothing will happen, and there's
no way to close the Bar workspace via the menu.

PROBLEM 2:
If I open Foo and Baz, then files A, B, C, and D will be open. The
Workspaces menu will have checks next to Foo, Bar, and Baz. If i select the
Foo workspace in the Workspaces menu to close it, then only file A will be
closed because it doesn't belong to any other open workspace. B won't be
closed because it belongs to Bar and Bar was deemed "open" since all its
files were open.


Again, I think automatically considering a workspace open just because
all the files are present in the editor leads to trouble.

There are other similar scenarios, but i guess they all at least partly stem
from how i'm currently determining whether a workspace is open. Right now,
a workspace is open if all its files are open, regardless of HOW they were
opened (e.g. via selecting the item in the Workspaces menu, opening the
file(s) by double-clicking in the project/source/classpath pane,
CTRL-N/CTRL-SHIFT-N, etc.)

I could probably change things around so that a workspace is only considered
open if you explicitly select it to be open via the Workspaces menu, but i'm
so far undecided whether that's more beneficial/intuitive.

Thoughts?


I can't think of why would I want one of my workspaces to get checked
behind the scenes just because I happened to open all the files in it.
Seems to me that the user should be explicitly opening and closing
workspaces.

Oh, that makes me remember a feature request I was thinking about
recently where workspaces marks on the editor tab (as an option, of
course) any files that aren't in any of the open workspaces. With a
feature like this and the current approach, once you hit that next
non-workspaced file, a group of non-workspaced files suddenly switches
to workspaced. That highlights the non-explicit strangeness of the
current approach and would argue for explicit workspace selection only.

Thanks,
Jon

0
Comment actions Permalink

My personal preferences:
- always have to open the workspace explicitly (loads all unloaded member
files)
- closing a member file keeps workspace open
- closing a workspace closes its member file iff it is not member file of
another open ws.

That behavior would be natural for me.
But that doesn't say anything about others' preferences.
Definitely, it solves you dilemma.

r.

"Chris Bartley" <spam@feynman.org> wrote in message
news:an9nnb$m5i$1@is.intellij.net...

I've been thinking more about this, and am not sure how to handle a few
cases. First, assume i have the following:

>

  • Workspace Foo contains files A and B

  • Workspace Bar contains files B and C

  • Workspace Baz contains files C and D

>

PROBLEM 1:
If I open Foo and Baz, then files A, B, C, and D will be open. The
Workspaces menu will have checks next to Foo, Bar, and Baz. If i select

the

Bar workspace in the Workspaces menu to close it, but files belonging to
other open workspaces aren't closed, then nothing will happen, and there's
no way to close the Bar workspace via the menu.

>

PROBLEM 2:
If I open Foo and Baz, then files A, B, C, and D will be open. The
Workspaces menu will have checks next to Foo, Bar, and Baz. If i select

the

Foo workspace in the Workspaces menu to close it, then only file A will be
closed because it doesn't belong to any other open workspace. B won't be
closed because it belongs to Bar and Bar was deemed "open" since all its
files were open.

>

There are other similar scenarios, but i guess they all at least partly

stem

from how i'm currently determining whether a workspace is open. Right

now,

a workspace is open if all its files are open, regardless of HOW they were
opened (e.g. via selecting the item in the Workspaces menu, opening the
file(s) by double-clicking in the project/source/classpath pane,
CTRL-N/CTRL-SHIFT-N, etc.)

>

I could probably change things around so that a workspace is only

considered

open if you explicitly select it to be open via the Workspaces menu, but

i'm

so far undecided whether that's more beneficial/intuitive.

>

Thoughts?

>

thanks,

>

chris

>

"Jon Steelman" <steelman@mindspring.com> wrote in message
news:an2anj$d3b$1@is.intellij.net...

Hi Chris,

>

Interesting the way you've approached workspaces. It seems you've given
the ability (by default) to combine your workspaces. One thing about
this, though, is that if I open two workspaces that have a file in
common, then close one workspace, the common file is removed from the
editor. So, the editor now won't contain all the files in the workspace
that remains open. Don't we want the closing workspace to leave open
files that are part of other open workspaces?

>

Thanks,
Jon

>
>


0
Comment actions Permalink

I'm thinking about #1 and #3, but am not sure about #2.

For example, say i do the following:
1) Start out with no files open
2) Select the Foo workspace to open files A and B
3) Close A and B via choosing "Close All Editors" in the File menu

You think the Foo workspace should remain checked in the Workspaces menu
because i never explicitly closed it, even though none of its files are
open? The only way to reopen the workspace would be to select it
twice--once to "close" it (mark it unchecked), and again to open it (mark it
checked). To me, such behavior defeats the purpose of the checkmark.

Maybe all this calls for a different Workspaces UI? Perhaps a pane (a la
Project, CVS, etc) instead that could show more info? Thoughts?

thanks,

chris

"Richard Nemec" <rndzank@attbi.com> wrote in message
news:an9oon$nvt$1@is.intellij.net...

My personal preferences:
- always have to open the workspace explicitly (loads all unloaded member
files)
- closing a member file keeps workspace open
- closing a workspace closes its member file iff it is not member file of
another open ws.

>

That behavior would be natural for me.
But that doesn't say anything about others' preferences.
Definitely, it solves you dilemma.

>

r.



0
Comment actions Permalink

Duh. I'm having one of those really hazy, stupid mornings. When i wrote
"I'm thinking about #1 and #3, but am not sure about #2" in my last post, i
was referring to to your preferences, not the steps in my following example.

I need more sleep :)


0
Comment actions Permalink

Chris Bartley wrote:

I'm thinking about #1 and #3, but am not sure about #2.

For example, say i do the following:
1) Start out with no files open
2) Select the Foo workspace to open files A and B
3) Close A and B via choosing "Close All Editors" in the File menu

You think the Foo workspace should remain checked in the Workspaces menu
because i never explicitly closed it, even though none of its files are
open? The only way to reopen the workspace would be to select it
twice--once to "close" it (mark it unchecked), and again to open it (mark it
checked). To me, such behavior defeats the purpose of the checkmark.


I agree with the Richard has articulated-- it is intuitive for me as well.

Well, maybe if you close the very last file from a workspace, then the
workspace should become unchecked.

Maybe all this calls for a different Workspaces UI? Perhaps a pane (a la
Project, CVS, etc) instead that could show more info? Thoughts?


I think the current UI is sufficient for now... but if you want to
make things more explicit, consider two counts next to the workspace in
the menu:

  • # of ws files in editor.

  • # of files grouped in ws.

Something like this: MyWorkspace 4 / 6
That way you could see even for unselected workspaces how many files are
in the editor. You would also see if you have depleted files from a
checked workspace.

Jon

0
Comment actions Permalink

Again, I think automatically considering a workspace open just because
all the files are present in the editor leads to trouble.


What kind of trouble?

Also, what about the reverse? To me, it's much more intuitive that if i
open workspace Foo (containing files A and B) and then individually close A,
B, or both A and B, then workspace Foo shouldn't be marked as checked (i.e.
open) in the Workspaces menu (see the related discussion in this thread
started by Richard Nemec). In my mind, a workspace isn't open unless all
its files are open, since a workspace is nothing more than a named set of
files (and thus my motivation for the current implementation where a
workspace is marked open if all it files are open, regardless of how they
were opened).

Oh, that makes me remember a feature request I was thinking about
recently where workspaces marks on the editor tab (as an option, of
course) any files that aren't in any of the open workspaces. With a
feature like this and the current approach, once you hit that next
non-workspaced file, a group of non-workspaced files suddenly switches
to workspaced. That highlights the non-explicit strangeness of the
current approach and would argue for explicit workspace selection only.



I'm sorry, I don't follow the "once you hit that next non-workspaced file, a
group of non-workspaced files suddenly switches to workspaced" part.

(sorry if i'm just being stupid--like i mentioned in the discussion with
Richard, i'm having one of those hazy, not-enough-sleep mornings :)

thanks,

chris

"Jon Steelman" <steelman@mindspring.com> wrote in message
news:an9on5$nru$1@is.intellij.net...

Chris Bartley wrote:

I've been thinking more about this, and am not sure how to handle a few
cases. First, assume i have the following:

>

  • Workspace Foo contains files A and B

  • Workspace Bar contains files B and C

  • Workspace Baz contains files C and D

>

PROBLEM 1:
If I open Foo and Baz, then files A, B, C, and D will be open. The
Workspaces menu will have checks next to Foo, Bar, and Baz.

>

Why would Bar have a check next to it? Seems like only Foo & Baz should
have a check even if all the Bar files happen to be open in the editor.

>

If i select the
Bar workspace in the Workspaces menu to close it, but files belonging to
other open workspaces aren't closed, then nothing will happen, and

there's

no way to close the Bar workspace via the menu.

>

PROBLEM 2:
If I open Foo and Baz, then files A, B, C, and D will be open. The
Workspaces menu will have checks next to Foo, Bar, and Baz. If i select

the

Foo workspace in the Workspaces menu to close it, then only file A will

be

closed because it doesn't belong to any other open workspace. B won't

be

closed because it belongs to Bar and Bar was deemed "open" since all its
files were open.

>

Again, I think automatically considering a workspace open just because
all the files are present in the editor leads to trouble.

>

There are other similar scenarios, but i guess they all at least partly

stem

from how i'm currently determining whether a workspace is open. Right

now,

a workspace is open if all its files are open, regardless of HOW they

were

opened (e.g. via selecting the item in the Workspaces menu, opening the
file(s) by double-clicking in the project/source/classpath pane,
CTRL-N/CTRL-SHIFT-N, etc.)

>

I could probably change things around so that a workspace is only

considered

open if you explicitly select it to be open via the Workspaces menu, but

i'm

so far undecided whether that's more beneficial/intuitive.

>

Thoughts?

>

I can't think of why would I want one of my workspaces to get checked
behind the scenes just because I happened to open all the files in it.
Seems to me that the user should be explicitly opening and closing
workspaces.

>

Oh, that makes me remember a feature request I was thinking about
recently where workspaces marks on the editor tab (as an option, of
course) any files that aren't in any of the open workspaces. With a
feature like this and the current approach, once you hit that next
non-workspaced file, a group of non-workspaced files suddenly switches
to workspaced. That highlights the non-explicit strangeness of the
current approach and would argue for explicit workspace selection only.

>

Thanks,
Jon

>


0
Comment actions Permalink

Chris Bartley wrote:
>>Again, I think automatically considering a workspace open just because
>>all the files are present in the editor leads to trouble.


What kind of trouble?

Also, what about the reverse? To me, it's much more intuitive that if i
open workspace Foo (containing files A and B) and then individually close A,
B, or both A and B, then workspace Foo shouldn't be marked as checked (i.e.
open) in the Workspaces menu (see the related discussion in this thread
started by Richard Nemec).


I can accept this one variant on only explicit workspace on/off.

In my mind, a workspace isn't open unless all
its files are open, since a workspace is nothing more than a named set of
files (and thus my motivation for the current implementation where a
workspace is marked open if all it files are open, regardless of how they
were opened).


Don't see it that way myself. I think I'm still in the workspace of 10
files even if I close one of the 10 tabs. Until I uncheck the workspace
or close the last tab, I'm still in it to my way of thinking.

See my other post with suggestion on showing two numbers on the
workspace entry.

>>Oh, that makes me remember a feature request I was thinking about
>>recently where workspaces marks on the editor tab (as an option, of
>>course) any files that aren't in any of the open workspaces. With a
>>feature like this and the current approach, once you hit that next
>>non-workspaced file, a group of non-workspaced files suddenly switches
>>to workspaced. That highlights the non-explicit strangeness of the
>>current approach and would argue for explicit workspace selection only.


I'm sorry, I don't follow the "once you hit that next non-workspaced file, a
group of non-workspaced files suddenly switches to workspaced" part.


Not that important, but say you have one ws open. A 2nd unopened ws has
several of the files from the 1st ws and well as 2 additional files.
Once you happen to open the last additional file, then the editor tabs
for those 2 additional files will suddenly switch to workspaced (in this
new feature I was thinking about). This would seem strange to me.

Jon

0
Comment actions Permalink

Well, maybe if you close the very last file from a workspace, then the
workspace should become unchecked.


That's a very good suggestion.

r.


0

Please sign in to leave a comment.