Workspaces 0.7 Follow
Workspaces 0.7 is available at:
http://www.intellij.org/twiki/bin/view/Main/WorkspacesPlugin
Changes since version 0.6.1:
New UI (tool window instead of menu)
Renaming of workspaces
Removal of files from existing workspaces
Rearrangement of files in existing workspaces
Rearrangement buttons now work with multi-select
Open/close/remove multiple workspaces
Confirmation dialog for remove
Not backwards compatible with previous versions (sorry).
Source code included
I'd really appreciate any feedbackespecially from Swing guruson better
ways to do things and to help solve the several known issues (see Known
Issues list at above URL). (I can spell Swing, and that's about it, so
there are probably a ton of things that I'm doing in a really stupid way.)
Please sign in to leave a comment.
Chris,
Wow, you've taken the Workspaces plugin to a whole new level! This is
quite usable, attractive, and it's much more obvious what is going on.
Thanks,
Jon
P.S. I'm still lobbying for the preference setting on your Todo--
Provide a global workspace preferences panel to set options such as
"when closing a workspace, don't close files that belong to other open
workspaces"
Chris Bartley wrote:
Chris,
Here's some material for discussion before placing Feature Request on
the Workspaces' page.
I feel like double-clicking on the workspace should do something, but
what would be the best action for a double-click?
Have you considered Workspaces as folders on the workspace panel so that
one could open a workspace (and leave it open) to see the contents of
any # of workspaces?
Jon
Chris Bartley wrote:
Just a few things:
- Feature request: Create a New Workspace dialog should suggest a name
for the workspace by analysing the class names or package names of the
files. Examples: If all the class names start with "Foo" then suggest
"Foo" (compared on a captialised word basis). If all the classes are in
the com.foo.bar package then suggest "Bar".
- Feature Request: Assign a shortcut to a workspace like you can with
Ant targets. I'm not sure whether the shortcut should toggle the
workspace or just open all files of that workspace. What do you think?
- Double-clicking on a workspace name should open it. Should it close it
if it's already open? This should be consistent with the way the
shortcut works.
- Perhaps the checkmark next to each workspace should be clickable by
the user to toggle that workspace?
Ciao,
Gordon
--
Gordon Tyler
Software Developer, R&D
Sitraka -- Performance is Mission Critical
"Jon Steelman" <steelman@mindspring.com> wrote in message
news:ao7150$mr0$1@is.intellij.net...
>
Hey, thanks! :D Are the icons intuitive enough? It's pretty clear my
degree is not in art ;) Graphic designers are welcome to step in here...
>
>
With the new UI, what are your thoughts regarding explicit vs implicit
opening and closing of workspaces? Same as before? Right now, it uses an
implicit opening/closing scheme and i'm still not sold on the benefits of an
explicit scheme--in my mind, it just introduces too many inconsistencies.
Right now, there's no separate concept of a workspace being open--that is,
if all its files are open, then it's marked with a black check. If some of
its files are open, it's marked with a grey check. If none, then no check.
And it makes no difference HOW those files were opened/closed.
The thing i worry about when implementing a "when closing a workspace, don't
close files that belong to other open workspaces" feature is the case where
workspace A is a subset of workspace B. If both are open, and you close A,
then (in the current design) it'll just look like the close button doesn't
work because none of the files in A will be closed since they're all
contained in B which is also open. If i introduced the concept of explicit
open/close, then in this case i could simply flag A as "closed" and mark it
with a grey check (since its files are open and belong to another
workspace).
But two related cases just feel "weird" to me:
Manually opening all files belonging to a workspace. It'll be marked with
a grey check. But, explicitly opening it at this point doesn't get you
anything. That is, what's the point? Just to get a black check? I guess
it'll give you "file-closing protection" if you close another workspace that
shares some files and you have the "don't close files that belong to other
open workspaces" option turned on, but...
Manually closing one or more files belonging to a workspace. If explicit
closing is required, and is the only way to change a black check to grey or
none, then the black check is meaningless. Sure, it signifies that the
workspace is "open", but what does that mean? Nothing, in my mind,
especially since not all of its files are open.
You said in our discussion a couple weeks ago:
"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."
But i still don't get it. :D What does it mean (to you) to be "in" a
workspace? (i promise i'm not trying to be difficult...it just that since
you can't really do much with these things other than open and close them, i
don't share any sort of notion of being "in" a workspace (other than what
the little green ball shows in the tool window))
Would a concept of a workspace lock help clarify all this? Maybe a padlock
icon that you could toggle on/off for individual workspaces to prevent its
files from being closed by closing other workspaces? That way, you'll get
your feature, but the meaning of the black/grey check isn't blurred. You
can still manually close files belonging to a workspace, and the workspace
will be marked with a grey check, but the lock will remain and prevent any
remaining files from being closed by closing another workspace. I kinda
like this, actually. Thoughts?
thanks,
chris
"Jon Steelman" <steelman@mindspring.com> wrote in message
news:ao73ad$p28$1@is.intellij.net...
>
Ah! I knew i forgot something in the To Do list! Yes, i definitely want
double-click to work. I started it, but gave up after a few minutes
because, well, i didn't really know what i was doing :D I think i assigned
the mouse listener to the JList or something and couldn't get at the actual
item (without some sorta roundabout hack). There's gotta be a clean way of
doing it, but i don't know it yet.
I'm thinking right now that double-click should fully open a workspace if
none or some of its files are open and fully close the workspace if all its
files are open. Thoughts?
I'll add double-click to the To Do list right away...
Hoo boy...i considered it a major achievement just to display them in a
list! :D That would be really smooth, though (especially if you could open
individual files, remove them by right-clicking, etc). I'm afraid that'll
hafta wait, though, until i learn more about Swing or someone wants to pitch
in and help.
chris
good news that!
"Chris Bartley" <spam@feynman.org> schrieb im Newsbeitrag
news:ao6vtq$l83$1@is.intellij.net...
>
>
>
>
>
>
"Gordon Tyler" <gordon.tyler@sitraka.com> wrote in message
news:ao7497$pvg$1@is.intellij.net...
>
Added to the feature request section on the Wiki page.
I used to have this one the to do list (but took it off because i was
feeling lazy). I messed around with this a bit, but had trouble with it due
to multi-project support. I couldn't figure out how to register/unregister
key mappings when switching projects. Anyone have any examples? I'll add
this back to the feature request section on the Wiki page. I think it
should probably work like double-clicking (see my other post to Jon about
double-clicking).
Yeah, i completely forgot to put that on the To Do list. It's one of my top
priorities (i double-click the dang things all the time :) See my other
post to Jon about double-clicking. It's on the To Do list now.
To work like double clicking the name? I agree. Added to the feature
request section on the Wiki page.
>
>
>
Chris Bartley wrote:
>>Chris,
>>
>>Here's some material for discussion before placing Feature Request on
>>the Workspaces' page.
>>I feel like double-clicking on the workspace should do something, but
>>what would be the best action for a double-click?
Agree on fully open. Don't feel as in favor of fully closing.
>>Have you considered Workspaces as folders on the workspace panel so that
>>one could open a workspace (and leave it open) to see the contents of
>>any # of workspaces?
Ok. Maybe should add it to the Feature Request so it isn't lost.
Jon
Chris Bartley wrote:
>>Chris,
>>
>>Wow, you've taken the Workspaces plugin to a whole new level! This is
>>quite usable, attractive, and it's much more obvious what is going on.
>>Thanks,
>>Jon
>>
>>P.S. I'm still lobbying for the preference setting on your Todo--
>>Provide a global workspace preferences panel to set options such as
>>"when closing a workspace, don't close files that belong to other open
>>workspaces"
Same as before. It doesn't matter so much now that the workspaces offer
so much nice feedback.
Yep.
If the "foldering" workspace gets implemented, this nesting can be taken
care of explicitly by actually nesting one workspace folder within another.
Well, one benefit of an explicitly opened workspace is that I don't have
to worry about any of its files being closed by virtue of closing
another workspace. The black check means I committed to these and they
won't get closed inadvertantly by closing another workspace. I still
like this better than the current behavior because it won't let one file
hang around in this scenario--
open 2 workspaces explicitly, A & B, workspaces with no shared files
one file in B happens to be in another workspace C.
when I close workspace B explicitly, the file shared with C won't
close due to my settings-- settings that I'm using to trying to emulate
explicit workspace opening.
It means don't implicitly close those files. Another workspace may have
all files open by coincidence, but I don't mind and even want that other
workspace to get its files closed implicitly. I can't make that
distinction with the current functionality.
See above.
I like the black/grey distinction (for all versus some files open in
editor) regardless which approach is taken. As far as the icon goes,
maybe a pin to represent pinning it down... the padlock seems more like
read-only to me. You could have a general setting that says whether
manually selecting a workspace automatically pins it down. I would turn
it on and you might leave it off, but such an option shouldn't impact
workspaces that get opened implicitly by its files being opened (they
are not pinned down automatically). With such an option on top of
pinning, I'd have my feature fully formed.
Thanks,
Jon
"Chris Bartley" <spam@feynman.org> wrote in message
news:ao79jo$uh9$1@is.intellij.net...
an
I'd like to try the explicit approach...
don't
where
A,
explicit
it
Yes, this is the behavior I'm thinking about.
>
with
that
In my mind, black check is: workspace is open (explicitly, some files may
have
been closed, the file-closin protection is on), no check means closed, grey
check is closed but some files are open (from other ws or manually).
explicit
or
Well, for me, black checks have a state information: I'm working on these
areas.
Don't close their files unless I do it either by closing the WS or closing
the
files manually. But I want to verify this in real.
padlock
This is the same file-closing protection as you have in 0.8 options but
moved at the individual workspace level. It is definitely more powerful.
Perhaps the option setting "don't close..." could be a default for the
workspace-level lock.
One more note: the lock symbol may easily associate with not being
able to close or modify the workspace and that's not true.
Have a nice day
r.