Community
Participate
Working Groups
I20070207-0010. When something is written to std out or err I can choose that the Console view is shown i.e. opened if not yet open. I would like the same option for the Error log view. Currently I am forced to 1. manually open it the first time 2. make it a fast view 3. let it stay around as fast view even though I normally don't want to see it From now on the view is activated on a log entry because the view menu's activate menu item is checked.
tagging bugday
Created attachment 82402 [details] mylyn/context/zip
There are a couple of ways to do this: 1. Log View in target Eclipse adds itself as a log listener immediately at platform start instead during plug-in start. Then Log View wouldn't be lazy any more = bad. 2. Log View in host Eclipse automatically opens target Eclipse log. Requires Log View to listen on log changes in file system, which requires polling = bad. 3. Log View in host Eclipse eats stdout instead of Console. That's doable, but then user wouldn't have console. = bad. I'll try 2. and if it is really that bad, go for 3....
*** Bug 209162 has been marked as a duplicate of this bug. ***
I'll probably have a look at this one, I'm definitely in my logview days :) Being loglistener in the "target" Eclipse sounds like a better solution to me. The feature should work even for someone who's not developing plugins and just uses the logview as a "final user", right ?
(In reply to comment #5) > I'll probably have a look at this one, I'm definitely in my logview days :) > > Being loglistener in the "target" Eclipse sounds like a better solution to me. > The feature should work even for someone who's not developing plugins and just > uses the logview as a "final user", right ? yes, the only drawback is that logview plug-in wouldn't be lazy loaded any more.
(In reply to comment #6) > yes, the only drawback is that logview plug-in wouldn't be lazy loaded any > more. > How about if we registered a LogListener on PDEPlugin initialization ? Something like : Platform.addLogListener(new ILogListener() { public void logging(IStatus status, String plugin) { try { PlatformUI.getWorkbench(). getActiveWorkbenchWindow().getActivePage(). showView("org.eclipse.pde.runtime.LogView"); } catch (PartInitException e) { } } It works well, but the feature would then need PDEPlugin to work, and the log view is now totally independent ...
good idea Ben this would fix the bug. But the other thing that makes me sad is that given that we're working on having hyperlinks in error log, it would make sense to show error log view in host Eclipse. There we could open hyperlinks because user's all plug-in code is in host workspace. Since we have log browser in error log, it would be easy to automatically switch in host error log view to display launched Eclipse instance log. Ah but that requires also catching up with log changes, or streaming log directly to host listener.
The suggested fix from comment 7 is a no go as it would make the feature unpredictable since it depends on PDE UI being loaded. >1. Log View in target Eclipse adds itself as a log listener immediately at >platform start instead during plug-in start. Then Log View wouldn't be lazy any >more = bad. There is no other way. The log view plug-in should offer that preference which is off by default and if enabled the log view plug-in is started on start up where it adds the listener. This is not so bad as this is a small plug-in. Also, the preference can warn the user: [ ] Show when on an entry is logged (activates Log view plug-in on startup) Re comment 8: please don't let your additional wishes hold off fixing this bug. My request is to open the view in workbench X if a log entry for it is written. If you have more ideas I suggest to file a new enhancement request ;-)
(In reply to comment #9) > The suggested fix from comment 7 is a no go as it would make the feature > unpredictable since it depends on PDE UI being loaded. > > >1. Log View in target Eclipse adds itself as a log listener immediately at > >platform start instead during plug-in start. Then Log View wouldn't be lazy any > >more = bad. > There is no other way. The log view plug-in should offer that preference which > is off by default and if enabled the log view plug-in is started on start up > where it adds the listener. This is not so bad as this is a small plug-in. > Also, the preference can warn the user: > > [ ] Show when on an entry is logged (activates Log view plug-in on startup) hm I thought of using org.eclipse.ui.startup ext point to make this plugin start early, but there's no way to add any preference there. Were you thinking of any other particular way to early start this plugin?
>hm I thought of using org.eclipse.ui.startup ext point to make this plugin >start early, but there's no way to add any preference there. The log view could add its own preference page but the real show stoppers here are: 1. the startup extension cannot be off by default 2. there is no API for clients to disable an auto-start plug-in - only users can do this via UI currently. Platform UI would have to enhance the extension point and provide an API along the lines of IWorkbench.setEarlyActivatedPlugin(String pluginId, boolean state). For now a simple "fix" would be to offer a simple plug-in that I can add to my install which simply implements this feature. Users that install it know what they do and can disable it via General > Startup and Shutdown. Once Platform UI has provided the additional APIs the code can move to the log view plug-in.
Created attachment 91116 [details] patch Now in early startup Activator adds itself as framework listener and on first coming log entry shows view. Quite like Ben described, but all happens in logview plug-in, not pde.ui. Hope Dani, you'll like it. Thank you both for making it happen :) I'll check if there's any bug for Platform UI changes outlined by Dani and if not create new.
(In reply to comment #12) > Now in early startup Activator adds itself as framework listener and on first I mean framework log listener (org.eclipse.core.runtime.ILogListener)
(In reply to comment #12) > I'll check if there's any bug for Platform UI changes outlined by Dani and if > not create new. created bug 220891
We should not do this until bug 220891 is fixed. Besides that the patch has two problems: 1. it uses the deprecated version of the extension point which relies on the compatibility plug-in. Instead, a new class that implements IStartup should be introduced and registered. 2. it does not remove the listener when the plug-in is stopped.
(In reply to comment #15) > We should not do this until bug 220891 is fixed. Besides that the patch has two > problems: correct. I also found another problem that makes it necessary to use separate IStartup, not only Activator.
Created attachment 91157 [details] patch Patch updated to: - define a separate IStartup class. - unregister loglistener on bundle stop - add a preference within LogView which tells if view should be opened or not. I found that regardless IStartup, view is usually started anyway because pde.ui depends on it. This way view popped up even if IStartup was disabled. With this patch, to enable early startup one will have to open view for first time, uncheck "Activate on new events" and check it again. Then say YES to additional question "Do you want to activate view even if it's closed? Answering no view will be activated only if it's already visible."[*]. That's because by default earlyStartup is disabled but "active on new events" is enabled. When bug 220891 gets fixed, one will also have to enable earlyStartup as well. It's most hidden feature of 3.4 :) [*] - this message may need rewording.
>I found that regardless IStartup, view is usually started anyway because pde.ui >depends on it. Yes, if Package Explorer or Project Explorer is open and the ExternalPluginLibrariesFilter enabled. >This way view popped up even if IStartup was disabled. This is because your patch is wrong. IStartup.earlyStartup() is not called when disabled. Of course you must add the listener there and not in start().
(In reply to comment #18) > This is because your patch is wrong. IStartup.earlyStartup() is not called when > disabled. Of course you must add the listener there and not in start(). ok, I assumed if plugin is already started, then earlyStartup is not executed. indeed wrong :|
Created attachment 91174 [details] patch compared to previous patch: - register log listener in IStartup.earlyStartup() - get rid of confirm dialog. wait for bug 220891 to do enable/disable
On a second thought we should use the startup extension point. We would have to synchronize the Error log view preference with the startup preference and the other way around. This is strange for the user. Also, the plug-in would show up on the 'Startup and Shutdown' preference page which it shouldn't (the loading is an implementation detail). A better solution would be a new extension point where plug-ins can register for log events via extension point.
(In reply to comment #21) > > A better solution would be a new extension point where plug-ins can register > for log events via extension point. I would prefer something that used the new ExtendedLogReader service in Equinox instead of introducing a new extension point. Unfortunately the ExtendedLogReader service suffers from the same issue as the ILogListener where you must progratically register the listener. We could allow LogListeners to be registered as OSGi services. This would allow you to use DS to declare a LogListener. But other details would need to be worked out, such as how to declaratively define a LogFilter so that you only get the log entries that go to the .log file. I'm not sure I have time to contain such a change in 3.7 though.
> We could allow LogListeners to > be registered as OSGi services. This would allow you to use DS to declare a > LogListener. But other details would need to be worked out, such as how to > declaratively define a LogFilter so that you only get the log entries that go > to the .log file. > > I'm not sure I have time to contain such a change in 3.7 though. There's no rush. I'm happy if we can put it on the plate for 3.8.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant please remove the stalebug whiteboard tag.
