RYann's dashboard

Because of your answer, I tried a lot of pictures... and the situation is even weird :-(
- for "small" image, it seems to behave as I think it would (small means image smaller than the display)
- but for many other images, bigger than my display, I have so different results (and often surprising) that I'm no longer sure of the meaning of each option.

As far as I understand:
1) "Fit to Screen" should never truncate anything of an image, BUT you can get empty bands (horizontal or vertical depending on the ratio) to fill the screen?
=> Nevertheless, I got some pictures where the upper and lower bands were not visible.

2) "Fill Screen" should, on the opposite, adapt the smaller dimension of the image to the display, and therefore some bands of the image would be invisible?
=> As mentioned above, I have some images where it oesn't work.

3) "Stretch to fill Screen" seems to be OK each time for me: unlike the two previous transformation, this one is not supposed to keep the aspect ratio and simply fill the display with the original image.
=> it works!

4) "Center" => OK

5) "Tiled" => OK

Then before going deeper into this bug, would you be kind to
- confirm that my understanding of each option, decribed above, is correct.
- an maybe try some various "big" images on your side to maybe see some bad cases like mine?

Yeah, nice! Congratulations.
To make it perfect in a future stable release, maybe you could allow a user-defined text for the notification?

One simple and user-friendly idea to implement it could be to add a usual '?' (or another icon) after the two preference lines to have more informations:
x When changing Spaces (?)
x When adding or removing Spaces (?)

a. Hover this symbol (?) would show the current text as tool-tip
b. Clicking this symbol would open an input textfield to replace
"You changed spaces to '%s'." by any user-defined text or to restore the default one.

This would also simply enable us to localize this text to our language.

P.S. Of course, it's not so simple to edit the four texts concerned by the second notification line ("you added/removed a column/line...") But I'm sure you'll have a great idea! Or simply allow the customization to only the first one?

Wouah, how fast!
My answer is "yes and no".

Yes it solves some problems.
Yes (BTW) it solves another bug I noticed: the drag'n'drop of images to the Preference pane.

But no, it's not totally solved :

=> For instance, the following image attached to this message has "vertical" dimensions (height > width) and, from my point of view, has a bad behavior with the option "Fill Screen" since only half the screen is filled and its center is strangley placed.

As far as I understand this "Fill Screen" option, this should fill the whole current display, by zooming or unzooming the image to the best fitted factor, but without visual deformation (keep the aspect ratio) :

a sort of "Fit to screen", but instead of making the larger dimension fit to the screen (and resulting in empty vertical or horizontal bands), this option would make the smaller dimension fit to the screen (and resulting in hidden vertical or horizontal bands).
Am I wrong?

By the way, what about the "evolution" of this new great feature?

- having all the entries of the MenuBar icon also in the Dock icon?
- having a user-friendly preference to enable this Dock icon?
(e.g. Sort of preference list of choice "Icon: MenuBar/Dock/Both)

Thank for the effort again of adding a first menu, that's nice!

> I got it, and edited the "LSUIElement" option.
For the newcomers, that means for instance to double-click in the Finder on Hyperspaces.app/Contents/Info.plist that will open the Property List Editor.

Then you just have to uncheck the line "Application is agent (UIElement)" and save.

Yes, now it changed ;-) but there is still a problem with drag'n'drop of image to the preference pane (whereas the new drag'n'drop to the Dock icon works perfectly):

- one is still allowed to perform a drag'n'drop to the preference pane (a nice green '+' is appearing)
- but it doesn't replace the current image:
1) the thumbnail remains the same
2) the desktop background remains the same

=> the drag'n'drop action is then allowed, but totally ignored ;-)

Maybe Hyperspaces will become totally "hyper" and integrate all-in-one.

But you can all the same start using Hyperspaces for now since, for the moment, you have a solution by adding Dock Spaces to get multiple docks: http://www.nscoding.co.uk/dock.html

Maybe would there be a solution to address Jonathan's wish nevertheless:

if Hyperspaces is currently able to change the desktop background each time the user selects another space (however it is: with Hyperspaces, with MacOS shortcuts, with another tool...), then it should be able to produce also the Growl notification in the same circumstances?

(which is indeed not the case currently: Hyperspaces notifies only changes made with Hyperspaces. But this behavior may also be the right one...)

I got it, and edited the "LSUIElement" option.
This worked perfectly. Great.

Nevertheless, to be perfect and let the Dock icon be as useful as the menubar icon (and eventually replace it when being the only one displayed), its action menu should lists the same contents...
=> for the moment About, Preferences and Help are missing...

By the way, I don't know if the Dock icon menu can have submenus (like the menubar icon) but when making those two menus identical, maybe the "About" item could go to the Help submenu (containing Updates and Contact)?

Thank you for the effort :-)

Yes, thank you Tony, I noticed that several of these suggestions have been integrated in the new release of Hyperspaces.

This is very kind of you.
You rock man!

Oh, yes, you got it!
You're a bit too addict to the keyboard ;-)

1) I can confirm that your own test (detailed above) work for me as well
(in other words: using the keyboard to select a new space in the graphical Switcher)

2) I can confirm (and that is the difference) that using the mouse and click to select a new space in the graphical Switcher give the resulting bug I described.

In short:
- with the keyboard, you can move the white rectangle to any of the spaces.
- with the mouse, normally you can move the white rectangle only to reachable spaces (that is to say all, except the current one). But with the described bug, the only one that is unselectable is always the #1 after relaunch.

So the bug concerns only mouse users!

The above idea could lead to a user interface a bit lighter by combining the 6 shortcuts by pairs on 3 lines only:

Switch to previous/next space: (click to record shortcut) (click to record shortcut)
Switch to up/down space: (click to record shortcut) (click to record shortcut)
Switch to left/right space: (click to record shortcut) (click to record shortcut)

@JB Segal

Those 2 different desired behaviors have been formerly been a nice subject of discussion I had with the author of Warp (this tool could be a solution for you to move from space to space the way you like, but with the Mouse and not the keyboard).

To give some precisions:
- Warp does exactly the move you wish
123>123>123 (horizontally)
147>147>147 (vertically)
Its author called this motion "à la Asteroids"

- Personnally I think "gravy" is too much :-) I used a lot of multiple desktop managers (from Unix stations to Mac... Windows and Linux being among my intermediate computers) and I always preferred the other behavior which is the current one of Apple Spaces that you detailed in your second message:
a) it does not roll over the borders, as you listed with "STOP" above: up and down moves will stop on the outside perimeter border.
b) it links 9->1 (or 1->9) with right (or left) moves since the underlying idea is to enumerate the spaces.
We could call this horizontal behavior "à la Spaces" ;-)

Maybe a better and satisfying solution would have been:
- in Spaces (because from my point of view Hyperspaces is not guilty),
having two kinds of shortcuts: arrow keys for your preferred moves "à la Asteroids" and +/- for enumerating moves "à la Spaces".
- the problem is that, to get the actual behavior of Spaces, users would have to use vertical arrows (vertically) and +/- (horizontally) which is not very natural.
- to make everybody satisfied, Apple should have introduced 3 configs in Spaces (where they currently have simplified into one):
Horizontal moves: ^ right & left (or any other user pref)
Vertical moves: ^ up and down (or any other user pref)
Enumeration moves : ^ + & - (or any other user pref)

Since Spaces is not so user-friendly, and that Hyperspaces is here to make Spaces become "hyper", one could rely on Hyperspaces (and Tony) to give a solution through Hyperspaces this way:

a) have Hyperspaces define its own shortcuts with all the possibility we hope,
in other words (but not very light):

Switch to next space: ^ > (for instance)
Switch to previous space: ^ < (by the way "previous" is here better than "last" space)
Switch to right space: ^ right arrow
Switch to left space: ^ left arrow
Switch to up space: ^ up arrow
Switch to down space: ^ down arrow

AND a user preference to enable the circular link (instead of stopping at the borders)
X Wrap spaces

b) if the user want to re-assign the same arrow-keys that are used as standard in Spaces, he would have to disable them manually from Spaces (or Hyperspaces could do it automatically? ;-))

Sound possible Tony?

Oh, how obvious, I forgot that Spaces was of course running too!
That explains clearly the fact that Hyperspaces, without any plist file, was starting directly in Space 2... Simply because Spaces was set in space 2... But that was not so obvious since I am now so used to have different background that my brain is "hard-coded" thanks to Hyperspaces ;-)

Besides this little point of fresh start that is now explained, I can only confirm the little bug in the Switcher that I observe when quitting Hyperspaces from another space than #1 and relaunching.

I cannot describe what I get more precisely than in my previous message, but to answer your questions:
- of course Apple Spaces is running (necessary for Hyperspaces)
- no other app concerning the spaces is running, except "Warp" (which is not really a virtual desktop manager): then I retried without Warp being activated, and the problem is the same.

I hope all this will make you able to see what I mean... and maybe to find the solution.
Maybe other users could confirm or not that they notice the same behavior of the Switcher after relaunching?

Very odd you can't reproduce this behaviour since it is possible everytime I quit for me. But I'm not sure we totally understood each other and I'll try to be more precise:

- switch to space 3 (or 4 or 2, but not 1) and quit Hyperspaces as you did.
- if you relaunch Hyperspaces I hope you'll see all this like me:

a) The desktop background of Space 3 reappears: perfect
b) Hyperspaces menu indicates you're in Space 3: perfect
c) The Switcher highlights Space 3 thumbnail (with a grey border): perfect
BUT
d) You cannot select Space 1 with its Switcher thumbnail: problem (it's a reachable space)
e) You can select Space 3 thumbnail: problem (it's the current space!)

After switching to another Space than the two concerned above (#1 and the one you quit, here #3), let's say after switching to space 2, then everything is OK again.

That's why I conclude as above...?
It's worth mentioning that this can be reproduced even if I restarted from scratch after I moved com.thecocoabots.Hyperspaces.plist to the Trash.

By the way, moving this preference list to the Trash surprised me: relaunching Hyperspaces after that displayed a "fresh" configuration, but directly placed in Space 2. Is it really the default space of Hyperspaces? (Maybe to show explicitely to the new user that there is several spaces?)