Announce and Discuss the Latest Theme and Extension Releases.
restart - was done prior to trying Ed's hack; quicklaunch not in use - Thank you.
I've looked at panels.rdf and might give it a go by editing a copy of the orig file. My SuiteRunner application and profile are relative (flash drive used on one or more PCs; not always the same drive letter). Do you have a clue on how I might reference a relative file location in the panels.rdf file? Would you think that either "//location/location/file" or "~//location/location/file" or "..//location/location/file" might work (without the quotes)? Any guess? I might try the trial and error approach ...
I'm thinking if there is a designation for a relative path that works, I might use an Opera Panel as a starting point.
Thanks for your interest. If I happen to stumble on to anything that works, I'll let you know; but it is not high on my priority list!
I am finding that SuiteRunner runs amazingly well considering it is intended to be an alpha version.
Thanks, also, for xSidebar. In addition to the Gcal web panel, there are 3 Opera Panels that I like (and have loaded), along w/ Scrapbook.
I haven't posted here before so I hope this winds up shown as a new post and not a reply to someone else's.
I decided to bite the bullet and install 1.1.7 along with this extension.
There is a general problem with extensions in SeaMonkey in that many of them insist on placing options in the context menu. The overall result makes the context menu very unpleasant to use, which is unfortunate because it is a mission-critical element. In the case of this extension (and most of the rest), it would be nice to have a preference checkbox or some other vehicle where the user could elect to place extension options in the context menu or not.
I have had enough experience modifying SeaMonkey, and Mozilla before that, that I was able to locate what had to be changed and make the changes, but I'd rather not be editing xsidebarNav.xul every time I update.
Actually, I just realized that I put xsidebarNav.xul in the profile folder so maybe that will be a permanant edit. I still think there is merit to giving the user control over the context menu where practical, however.
xSidebar's options are accessed via Edit->Preferences->xSidebar, or via the Configuration menu called from a button in the sidebar header. There is no link to xSidebar's options dialog from any context menu as far as I know.
Since you know how to use userChrome.css, a less hacky solution would be to add some rules to hide any context menu items you do not want to see. An even easier method would be to install the Stylish extension and use it's GUI to manage your styles dynamically.
"There is no link to xSidebar's options dialog from any context menu as far as I know."
I think my use of "options" is just a terminology problem. When I made the changes in xsidebarNav.xul, I saved the before-and-after in Word for future reference. Based on a check of that, the removed options (perhaps "commands" would be a better word choice) would appear to be:
Open Link in Sidebar
View Page inSidebar
View Source in Sidebar
Add page to Sidebars
Add Page to Current PanelList
I'll check into the suggestions you mention, and if the cure is not worse than the disease (an example of this being, IMO, an overly complex extension installed on a commendably simple application) I will give it a shot.
Something wrong goes some time: looks like sidebar of xsidebar works incorrect:
if I open sidebar, I see empty sidebar, and no sidebars in up menu of sidebar pane, and f9 button can open this pane, but can't close.
Are you using a recent trunk (2.0a) nightly build? This is a known problem on trunk.
Yes. Thank you.
Yes, I understand .
Who is online
Users browsing this forum: No registered users and 1 guest