Float toolbar on creation?
-
The Win version will list old toolbar names - toolbars that are no longer present, but still got remains in the registry.
Was thinking of running a loop testing against
UI.toolbar- but it will create a new toolbar if given the name of a non-existent toolbar. Acts likeUI::Toolbar.new. -
For Windows - I'm wondering if it'd be an option to use the Win32 API to read the menu items from the Toolbar menu...
-
A new Windows solution. It uses the Win32 API to read the menu items under
View->Toolbars. This should allow the list returned to be up to date at any point - even after new toolbars has been created. And it won't list old names.Only thing is that I'm not sure how to get the SU window handle...
Wonder if similar can be done under OSX...
-
What I was thinking (somebody stop me) was hiding all toolbars before creating the new toolbar. Then the user can un-dock it. Finally, unhide all the hidden toolbars. But it's a terrible hack.
-
Does that avoid the shifting of toolbars? It seems to be that the toolbars shift when the Toolbar object is created - even before the toolbar is ever shown.
-
have you guys considered making a dialog window the first time a new plug runs that asks if you would like to run the plug (after all the existing toolbars are loaded) then insert the new toolbar. that way the old toolbars will be in place already, avoiding the startup scramble? (if its possible?)
-
That won't avoid the scramble either. Even if you add toolbars after all the other ones are added it still inserts itself randomly between toolbars.
Selection Toys has a function where the user has to enable to toolbar before it can be accessible. Doesn't prevent the mess though.
-
So to sum-up this thread, the API methods for managing Toolbars is either broken or lacks functionality in order to be effective?
-
It sure is a mess. It does seem it's possible to enumerate the Ruby toolbar names.
But if the purpose is to prevent toolbars shifting about - then it's a fail.
-
does anyone even know how they organise themslves when they jumble? is it alphabetically, native tools first...?
would it be exactly the same if you had 2 computers with same layout then installed same new plug? -
I've not been able to notice any patterns.
-
I could never find a pattern - it's just chaos. Sometimes they have absolute positions (x, y), but others appear to use the equivalent of -1 as a coordinate and these seem to float inside the toolbar area.
-
its not even possible to be totally random on a computer is it?
has anyone ever tried on 2 machines to see if its the same? -
And I've never seen any other application where the toolbar behaves like this. No idea what kind of implementation it is.
Been using WinDowse to try to find some hints - but with no luck.
-
I'm don't want to put any more time into trying to reverse engineer them.
The conclusion I keep coming to is that a WebDialog-based User Interface Manager is the solution. But I'm not sure what that would look like.
-
You mean a webdialog instead of the toolbars?
I just came to think of this thread, http://forums.sketchucation.com/viewtopic.php?f=15&t=25676, where did guy have managed to embed the SU tool windows into the native SU frame.
What would be interesting would be to embedd a Webdialog like that and use that as a blank canvas. -
@jim said:
The conclusion I keep coming to is that a WebDialog-based User Interface Manager is the solution. But I'm not sure what that would look like.
One idea I've been playing with recently: a tool that launches other tools.
Then you could hide all toolbars. When you want to switch tool, you hit a shortcut that activates the tool that brings up a set of toolbars drawn on the viewport - like Fredo's tools.
Advertisement