Community
Participate
Working Groups
This is wrt the contribution in bug #69581 "[templates] Template view". That bug is already +100 comments long so I decided to post these (lengthy) remarks as a separate bug. This is based on loading patch 2007-10-19 into a recent build (I20071017) with latest source projects. Apologies if some things I've noted have already been well noted, the bug thread is quite long and I've not kept up with it all. 0) Its clear there's been a ton of work on this both from those contributing and from Dani in shepherding it along. Nice work. 1) This is kinda neat. Although I think I personally would use good ol' completion instead, I could see it being cool for visual editors. 2) I got one compile error: Referenced resource '$nl$/icons/full/eview16/templates.gif' in attribute 'icon' cannot be found org.eclipse.ui.workbench.texteditor plugin.xml line 1109 and most icons are missing (I assume from the discussion this is known). 3) I liked the fact that once I double-clicked on a template to insert it in the source, the editor then had focus. This is exactly correct and creates a natural flow. 4) I don't understand the purpose of "Link with Editor", both in theory and practice. Also I didn't see that it actually *did* anything. Theory: In navigators it makes sense because there's a 1:1 correspondence between resources in the navigator and the editor source, so given the latter you'd like to find the former. But templates become modified, that's their purpose, and are no longer the thing you picked from the list. Practice: Once I drop a template in, why would I want to find the template in the list again? 5) I liked the fact that by default it appears in the same stack as the Outline view. 6) The Preview area is so small to be useless even with the workbench maximized on a 1600x1200 screen. The problem is that the list is a skinny vertical thing, and the Preview needs to be horizontal. I'd need to resize the Template/Outline stack wider and waste space. Other user solutions is to dock it in the explorer stack, but that's kind of odd from a flow point of view, or use it was a fast view sized wide. An alternate design would be to show it in a yellow "quick" style popup but that'd require an additional step of picking it from a menu. I'd recommend removing it from the view (keep as popup) so I can get more list space. Or even just dropping it all together. I have undo anyway so if I don't like the result of applying the template then I can just undo it. But I'm just that kinda guy. I don't see myself ever looking at the Preview and assume most users wouldn't either. Finally, its not clear what it would do for a visual editor (especially in that real estate). 7) Some of the proposals ("for", "while") appear many times because there's variations on them. The labels need to be distinct so one can figure one from the other. The Preview isn't big enough to help. Perhaps postfix the description in the label but only for those which there are duplicates (to avoid clutter). Also recommend you show the template's description in its hover in the list. This is goodness anyway and would help with the duplicate problem but isn't enough on its own (you don't want to 'hunt' for the right one). 8) It seems some templates provide the ability to Run/Debug. But darn if I can figure out what I had selected to get those menu items added! The icons, or decorations on the icons, should tell you which you can do this with. More importantly, its not at all clear to me what it means to run/debug a template ... they're not *real*, by definition, and can't be run. 9) I see two icons in the list, one a kind of list'y thing on Java items, and the other an arrow for SWT items. No idea what they're trying to tell me. 10) Q: Can I use templates to create whole classes or even projects? Or are they only for insertion in text? I assume the latter, in which case maybe we want to call the view "Source Templates". Dunno. 11) Finally, I'll echo Dani's comment #102: if my configuration doesn't include JDT, I still have access to the Template view, but its content will forever be empty. This is pretty strange because I the user have no idea what I should do to get templates to appear in it (turns out, nothing will). This is very bad and I don't view the current state to be acceptable (ie. unfortunately I think I'd have to -1 the contribution). 12) The view is a bit toolbar happy. - I don't see the value of "Insert into Editor" because (1) I have a menu item for it if I'm exploring what I can do and (2) double click works just fine thank you and (3) cool I have drag and drop too. I don't need yet another way of dropping them in and once someone learns double click or D&D then they'll never use the toolbar icon, guaranteed. - Create/Edit/Remove are presumably infrequent actions. Toolbars OTOH are for frequent actions so from a UI guideline point of view these shouldn't be there. Plus, I have these actions in the menu, *and* in the preferences, I don't need them in the toolbar too. So I'd recommend declutter and remove all of those, leaving you with collapse all and link with editor (should you choose to keep the action, see (4) above). 13) The ability to insert a template appears to be sensitive to the editor's cursor location. For example, if I'm above the class def and have no imports, I can't insert. Yet the action is enabled. It should either be disabled, or a message should result, "Could not insert at the current edit location". 14) You have "Remove" but there's no clear way of getting them back. In the preferences page I found "Restore Removed" but lucky me. I assume you don't have "Restore" in the view because you can't see what you're restoring (a good choice then). As a solution, I'd recommend that since you prompt the user for confirmation on removal, you change the message to inform the user that he can get them back via the preferences page. 15) It should be "Insert", not "Insert...", since there's no resulting dialog. It could be "Remove...", and arguably "Edit", see http://dev.eclipse.org/blogs/kevinmcguire/2007/10/12/ellipsis-for-eclipses/ for a discussion on the subject. 16) Removal seems broken. I tried it and they weren't removed. Keep at it and eventually it gets annoyed and you get an error (let me know if you want the trace but the real error is that remove isn't working).
Thanks Kevin for this valuable and extensive feedback. We will address one by one but currently I'm busy with finalizing M3. Here some initial answers: >1) This is kinda neat. Although I think I personally would use good ol' >completion instead, I could see it being cool for visual editors. We are used to use code assist but often people ask us whether we have templates or not. This view makes them more visible and I don't think it is limited to visual editors. >2) I got one compile error: >Referenced resource '$nl$/icons/full/eview16/templates.gif' in attribute 'icon' >cannot be found org.eclipse.ui.workbench.texteditor plugin.xml line >1109 >and most icons are missing (I assume from the discussion this is known). Icons are binary files and hence not part of the patch itself. They are attached to the bug. >4) I don't understand the purpose of "Link with Editor", both in theory and >practice. Also I didn't see that it actually *did* anything. This narrows the visible templates down to those available in the current context (e.g. Javadoc vs. code). If you only played withing code then you saw no diff.
(In reply to comment #1) > Thanks Kevin for this valuable and extensive feedback. We will address one by > one but currently I'm busy with finalizing M3. Here some initial answers: No problem, hope its helpful. > >1) This is kinda neat. Although I think I personally would use good ol' > >completion instead, I could see it being cool for visual editors. > We are used to use code assist but often people ask us whether we have > templates or not. This view makes them more visible and I don't think it is > limited to visual editors. It will probably also be helpful for new users since its quite evident what is available to apply. We used templates with good success in WID. > >2) I got one compile error: > >Referenced resource '$nl$/icons/full/eview16/templates.gif' in attribute 'icon' > >cannot be found org.eclipse.ui.workbench.texteditor plugin.xml line > >1109 > >and most icons are missing (I assume from the discussion this is known). > Icons are binary files and hence not part of the patch itself. They are > attached to the bug. Doh! Of course. I'm an idiot. > >4) I don't understand the purpose of "Link with Editor", both in theory and > >practice. Also I didn't see that it actually *did* anything. > This narrows the visible templates down to those available in the current > context (e.g. Javadoc vs. code). If you only played withing code then you saw > no diff. Ah ok that explains it. I'll need to think more if "Link with Editor" is the best name since maybe for some, as in my case, it wasn't evident what was going on.
(In reply to comment #0) Kevin: Thanks for all the valuable feedback. Really appreciate the efforts you have put in. I will try to provide some answers - Dani might be able to answer questions regarding esthetics better. > 1) This is kinda neat. Although I think I personally would use good ol' > completion instead, I could see it being cool for visual editors. > I am also a big fan of Ctl/Cmd-Space completion. This view brings the templates out of the closet. More useful for creating new templates and cut&paste where necessary. > Finally, its not clear what it would do for a visual editor (especially in that real estate). > A visual editor can show a thumbnail view of the template in this area. Have a look at https://bugs.eclipse.org/bugs/attachment.cgi?id=76655 for a mockup. And also, does reducing the font size in preview pane help? Is there any standard font sizes that we can use for showing this? > 7) Some of the proposals ("for", "while") appear many times because there's > variations on them. The labels need to be distinct so one can figure one from > the other. The Preview isn't big enough to help. > > Perhaps postfix the description in the label but only for those which there are > duplicates (to avoid clutter). > The description is shown in a separate column already. > Also recommend you show the template's description in its hover in the list. > This is goodness anyway and would help with the duplicate problem but isn't > enough on its own (you don't want to 'hunt' for the right one). > Tooltips are not supported by Table/Tree by SWT. We need to listen to the mouse hover events to get this functionality. Is this OK to implement this way? > 8) It seems some templates provide the ability to Run/Debug. But darn if I can > figure out what I had selected to get those menu items added! The icons, or > decorations on the icons, should tell you which you can do this with. > > More importantly, its not at all clear to me what it means to run/debug a > template ... they're not *real*, by definition, and can't be run. > I did not understand? What templates provide Run/Debug options? Not the templates provided by Java editor/Ant editor. > 9) I see two icons in the list, one a kind of list'y thing on Java items, and > the other an arrow for SWT items. No idea what they're trying to tell me. > These are picked up from the icons defined by the editor (java editor in this case). > 10) Q: Can I use templates to create whole classes or even projects? Or are > they only for insertion in text? I assume the latter, in which case maybe we > want to call the view "Source Templates". Dunno. > The basic functionality is to insert text. Ant editor supports inserting a build file template if the file is a new file. It is possible for other editors to have new-file templates to create standard class files. I do not foresee template mechanism being used for projects. I might be wrong at that. > 11) Finally, I'll echo Dani's comment #102: if my configuration doesn't include > JDT, I still have access to the Template view, but its content will forever be > empty. This is pretty strange because I the user have no idea what I should do > to get templates to appear in it (turns out, nothing will). This is very bad > and I don't view the current state to be acceptable (ie. unfortunately I think > I'd have to -1 the contribution). > The fix is also simple like Dani suggested. Move the template contribution to JDT plugin.xml. I am not comfortable with it as most of the code resides in the texteditor and each product that wants to enable templates view needs to define the contribution in their plugin.xml. Another suggestion I have is that a default template category for all text editors that is visible in all contexts and useful for DnD text snippets. This will work as a persistent clipboard. I don't know how to go about it though. > 13) The ability to insert a template appears to be sensitive to the editor's > cursor location. For example, if I'm above the class def and have no imports, > I can't insert. Yet the action is enabled. It should either be disabled, or a > message should result, "Could not insert at the current edit location". > Disabling the action will entail lots of processing. Displaying a message is OK. Dani: Please comment. > 15) It should be "Insert", not "Insert...", since there's no resulting dialog. > It could be "Remove...", and arguably "Edit", see > http://dev.eclipse.org/blogs/kevinmcguire/2007/10/12/ellipsis-for-eclipses/ for > a discussion on the subject. > Remove asks for a confirmation. Insert might result in inserting a template with place holders into the editor, so there is still more information needed from the user. > 16) Removal seems broken. I tried it and they weren't removed. Keep at it and > eventually it gets annoyed and you get an error (let me know if you want the > trace but the real error is that remove isn't working). > It works for me. Are there any exceptions? Can you post the trace? -- KD
(In reply to comment #3) > Kevin: > > Thanks for all the valuable feedback. Really appreciate the efforts you have > put in. I will try to provide some answers - Dani might be able to answer > questions regarding esthetics better. Np, it was a small effort compared to the contribution :) > > Finally, its not clear what it would do for a visual editor (especially in that real estate). > > > A visual editor can show a thumbnail view of the template in this area. Have a > look at https://bugs.eclipse.org/bugs/attachment.cgi?id=76655 for a mockup. > > And also, does reducing the font size in preview pane help? Is there any > standard font sizes that we can use for showing this? Fonts are a problem. We only have a handful of standard ones and I don't think one will provide what you want. You can defined your own, but then you need your own preference, which nobody will find... I don't recommend that route. While a smaller font would help so you could actually see more of the preview, I just think you have a losing battle given the real estate you'd normally have to work with. I say "normally" based on my assumption of the typical layout, which for me for JDT would be overtop the outline as you have now, fairly narrow. I think either you need some other way of displaying it where it popups up and goes away, or you don't provide it at all and rely on Undo, which to me would be perfectly acceptable. I would understand though if you felt the need for some type of preview since code completion provides that presently via the yellow lightweight popup. > > 7) Some of the proposals ("for", "while") appear many times because there's > > variations on them. The labels need to be distinct so one can figure one from > > the other. The Preview isn't big enough to help. > > > > Perhaps postfix the description in the label but only for those which there are > > duplicates (to avoid clutter). > > > The description is shown in a separate column already. Wow, I didn't even know that column existed until you told me. With the Java Perspective when I opened the Template View in a new workbench at about 1200x1000, I didn't see it. The only clue is the horizontal scroll bar. That's going to be pretty typical. I think a second column, while good in its similarity to the corresponding preference page, doesn't work well here because of the narrow nature of the view in typical configurations. If one were using it as a fast view then ok but that's not the default. I'd recommend concatenation. > > Also recommend you show the template's description in its hover in the list. > > This is goodness anyway and would help with the duplicate problem but isn't > > enough on its own (you don't want to 'hunt' for the right one). > > > Tooltips are not supported by Table/Tree by SWT. We need to listen to the mouse > hover events to get this functionality. Is this OK to implement this way? Sorry I didn't describe that well. What I meant to say was that if you appended the description to the name, then if the string was too long to be visible, hover would reveal the extra by default (and basically for free. you're getting it now). You're right you can't easily override the hover behaviour and I'd recommend against custom solutions involving listeners. > > 8) It seems some templates provide the ability to Run/Debug. But darn if I can > > figure out what I had selected to get those menu items added! The icons, or > > decorations on the icons, should tell you which you can do this with. > > > > More importantly, its not at all clear to me what it means to run/debug a > > template ... they're not *real*, by definition, and can't be run. > > > I did not understand? What templates provide Run/Debug options? Not the > templates provided by Java editor/Ant editor. If I select "arrayadd" in the Templates view and popup the menu, I see "Run As", "Debug As", and "Profile As" menus with submenus. Now here's the fun part: as I wrote those words I was looking at the popup. I switched to bugzilla, went back to the workbench to double check, and they were gone from the popup. I have no idea what I did that changed it. I take it this is unintentional? :) > > 9) I see two icons in the list, one a kind of list'y thing on Java items, and > > the other an arrow for SWT items. No idea what they're trying to tell me. > > > These are picked up from the icons defined by the editor (java editor in this > case). Ok. I still don't know what they mean. Perhaps this is a bug to jdt/text then? Or is the problem they are being used out of context? > > 10) Q: Can I use templates to create whole classes or even projects? Or are > > they only for insertion in text? I assume the latter, in which case maybe we > > want to call the view "Source Templates". Dunno. > > > The basic functionality is to insert text. Ant editor supports inserting a > build file template if the file is a new file. It is possible for other editors > to have new-file templates to create standard class files. I do not foresee > template mechanism being used for projects. I might be wrong at that. OK that sounds reasonable. I only suggest "Source Templates" because as I looked down the list of views, I was wondering if a new user would know what to do with a "temapltes" view. Maybe "source" doesn't help much anyway, just trying to guess what a new user is thinking. > > 11) Finally, I'll echo Dani's comment #102: if my configuration doesn't include > > JDT, I still have access to the Template view, but its content will forever be > > empty. This is pretty strange because I the user have no idea what I should do > > to get templates to appear in it (turns out, nothing will). This is very bad > > and I don't view the current state to be acceptable (ie. unfortunately I think > > I'd have to -1 the contribution). > > > The fix is also simple like Dani suggested. Move the template contribution to > JDT plugin.xml. I am not comfortable with it as most of the code resides in the > texteditor and each product that wants to enable templates view needs to define > the contribution in their plugin.xml. > > Another suggestion I have is that a default template category for all text > editors that is visible in all contexts and useful for DnD text snippets. This > will work as a persistent clipboard. I don't know how to go about it though. This is a problem with Eclipse itself that we keep running into, where you'd like some base functionality but only expose it for particular optional plugins. Dani's solution is the best we can offer unfortunately. I don't think we should try to make the templates view in a sense more important to justify it being visible in the base, in particular because I think its artificial to produce templates for vanilla text editors. No corresponding code assist is there presently, because there was nothing of value to add, so why would we add templates? The templates are best when paired with a domain specific editor such as JDT. > > 15) It should be "Insert", not "Insert...", since there's no resulting dialog. > > It could be "Remove...", and arguably "Edit", see > > http://dev.eclipse.org/blogs/kevinmcguire/2007/10/12/ellipsis-for-eclipses/ for > > a discussion on the subject. > > > Remove asks for a confirmation. Insert might result in inserting a template > with place holders into the editor, so there is still more information needed > from the user. Re Insert: if you don't *always* have a resulting dialog/confirmation, then you can't use ellipses since its misleading. One reason for ellipses is to indicate to the user that they can "explore" the menu item without worrying about something happening right away. Re Remove: since it asks for confirmation you could use ellipses. But you can go either way on this one. Typically Delete has confirmation but no ellipses. One reasoning why is that you don't want to encourage people to "explore" it. Check out the blog entry since it has similar discussion. I'm happy to discuss further in some other thread so as not to make this one too long. > > 16) Removal seems broken. I tried it and they weren't removed. Keep at it and > > eventually it gets annoyed and you get an error (let me know if you want the > > trace but the real error is that remove isn't working). > > > It works for me. Are there any exceptions? Can you post the trace? Hmmm, I can't reproduce this and the log got overwritten. The stack trace wasn't the remove failing anyway, it was the fact that the remove had failed so the selection was invalid. I'll keep on the lookout for it and if I can get it to happen again I'll open a new bug for it.
Removed dependency to bug 208062 as this is neither related nor blocking this one.
We won't have time to do this for M4. Will be done early M5.
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
