Thread: [Freemind-developer] Toggle or not Toggle
A premier mind-mapping software written in Java
Brought to you by:
christianfoltin,
danielpolansky
From: Dimitry P. <dpo...@gm...> - 2007-12-03 22:07:57
|
Hello, Dan has requested to change English menu items as follows: > The following menu items are named inconsistently and should be renamed as > follows:* View > Selection Bubble on/off > **NEW: Toggle Selection Oval > * View > Show/Hide Note Window > **NEW: Toggle Note Window Because of my poor English i understand the old items, but can hardly understand the new ones. Could some people with good English validate the request, please. Dimitry |
From: Eric L. <fre...@zo...> - 2007-12-04 09:41:44
|
Hi, toggle is not wrong, but it's in deed more difficult to understand, and also to translate. If it's about consistency, I'd suggest to rename the first one to "Show/Hide Selection Bubble" (or Rectangle, the Selection Bubble is not oval but rectangular with round corners, which would be a bit too long though ;-) ). As we already use "Bubble" in the Format menu for the same form, perhaps we should just keep the same name, or use everywhere "Rounded Rectangle". Bubble is fine with me, even though I've never seen a bubble of such a form :-) While we're at it: Menu Tools -> Preferences... -> Appearance -> "Selected Node Buble color" ==> Buble should be with 2 B's! Eric Dimitry Polivaev wrote: > Hello, > > Dan has requested to change English menu items as follows: > >> The following menu items are named inconsistently and should be renamed as >> follows:* View > Selection Bubble on/off >> **NEW: Toggle Selection Oval >> * View > Show/Hide Note Window >> **NEW: Toggle Note Window > > Because of my poor English i understand the old items, but can hardly > understand the new ones. Could some people with good English validate > the request, please. > > Dimitry |
From: Ray B. <ray...@co...> - 2007-12-04 18:08:30
|
The menu items are inconsistent. I think I may have made a note of that somewhere, as well. I've just been looking at a few other Windows programs, to see how they handle View items that are turned on and off. Most of them just name the item. When it's on, a check mark is placed beside the item in the view menu. If we did this, the View Menu would be something like: Toolbar Left Toolbar ------------------------ Selection Rectangle Zoom In Zoom Out Zoom to Fit Page ----------------------- Note Window Attributes > Some applications use a sub-menu for the Zoom options. I think there are few enough they are fine where they are, but it might be useful to have icons associated with them, a magnifying glass with a plus sign for zoom in, and one with a minus sign for zoom out. This would help convey the meaning w/o translation. There doesn't seem to be an easily recognized icon for Zoom to Fit Page. Although, I could probably come up with something pretty easily. It might be helpful to have names for the two toolbars other than Toolbar and Left Toolbar. How about Main Toolbar and Icon Toolbar? Also, please put a check mark beside the options that are currently on. I know, in some cases, you can just look and see it's turned on, but it helps users if they get direct feedback on their actions. Ray Eric Lavarde wrote: > Hi, > > toggle is not wrong, but it's in deed more difficult to understand, and > also to translate. > > If it's about consistency, I'd suggest to rename the first one to > "Show/Hide Selection Bubble" (or Rectangle, the Selection Bubble is not > oval but rectangular with round corners, which would be a bit too long > though ;-) ). As we already use "Bubble" in the Format menu for the same > form, perhaps we should just keep the same name, or use everywhere > "Rounded Rectangle". Bubble is fine with me, even though I've never seen > a bubble of such a form :-) > > While we're at it: Menu Tools -> Preferences... -> Appearance -> > "Selected Node Buble color" ==> Buble should be with 2 B's! > > Eric > > Dimitry Polivaev wrote: > >> Hello, >> >> Dan has requested to change English menu items as follows: >> >> >>> The following menu items are named inconsistently and should be renamed as >>> follows:* View > Selection Bubble on/off >>> **NEW: Toggle Selection Oval >>> * View > Show/Hide Note Window >>> **NEW: Toggle Note Window >>> >> Because of my poor English i understand the old items, but can hardly >> understand the new ones. Could some people with good English validate >> the request, please. >> >> Dimitry >> > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > |
From: Dan P. <dan...@gm...> - 2007-12-04 18:32:39
|
Hi, Ray's proposal of leaving the verb out and adding the check marks to the menu item looks good to me. Just please consider that some of these menu items also appear in the map popup menu, so the check marks would have to be added there too. In any case, let us head for consistency, both of the new menu items like Selection Rectangle On/Off and the old menu items like Toggle Toolbar and Toggle Left Toolbar. Dan On Dec 4, 2007 7:08 PM, Ray Benjamin <ray...@co...> wrote: > The menu items are inconsistent. I think I may have made a note of that > somewhere, as well. I've just been looking at a few other Windows programs, > to see how they handle View items that are turned on and off. Most of them > just name the item. When it's on, a check mark is placed beside the item in > the view menu. If we did this, the View Menu would be something like: > > Toolbar > Left Toolbar > ------------------------ > Selection Rectangle > Zoom In > Zoom Out > Zoom to Fit Page > ----------------------- > Note Window > Attributes > > > Some applications use a sub-menu for the Zoom options. I think there are > few enough they are fine where they are, but it might be useful to have > icons associated with them, a magnifying glass with a plus sign for zoom in, > and one with a minus sign for zoom out. This would help convey the meaning > w/o translation. There doesn't seem to be an easily recognized icon for Zoom > to Fit Page. Although, I could probably come up with something pretty > easily. > > It might be helpful to have names for the two toolbars other than Toolbar > and Left Toolbar. How about Main Toolbar and Icon Toolbar? > > Also, please put a check mark beside the options that are currently on. I > know, in some cases, you can just look and see it's turned on, but it helps > users if they get direct feedback on their actions. > > Ray > > > Eric Lavarde wrote: > > Hi, > > toggle is not wrong, but it's in deed more difficult to understand, and > also to translate. > > If it's about consistency, I'd suggest to rename the first one to > "Show/Hide Selection Bubble" (or Rectangle, the Selection Bubble is not > oval but rectangular with round corners, which would be a bit too long > though ;-) ). As we already use "Bubble" in the Format menu for the same > form, perhaps we should just keep the same name, or use everywhere > "Rounded Rectangle". Bubble is fine with me, even though I've never seen > a bubble of such a form :-) > > While we're at it: Menu Tools -> Preferences... -> Appearance -> > "Selected Node Buble color" ==> Buble should be with 2 B's! > > Eric > > Dimitry Polivaev wrote: > > > Hello, > > Dan has requested to change English menu items as follows: > > > > The following menu items are named inconsistently and should be renamed as > follows:* View > Selection Bubble on/off > **NEW: Toggle Selection Oval > * View > Show/Hide Note Window > **NEW: Toggle Note Window > > > Because of my poor English i understand the old items, but can hardly > understand the new ones. Could some people with good English validate > the request, please. > > Dimitry > > > -------------------------------------------------------------------------SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future.http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Freemind-developer mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/freemind-developer > > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > |
From: Dan P. <dan...@gm...> - 2007-12-04 18:49:14
|
Hi, regarding the titles of "Toolbar" and "Left Toolbar": it would certainly be okay to rename "Toolbar" to "Main Toolbar". Also, the name of the currently left toolbar could be specific to mode, so the mode controller or the mode could return the name of the left toolbar, better designated as secondary toolbar, using a method implemented for the mind map mode as String getSecondaryToolbarTitle() { return getText("icon_toolbar"); } I have used the name "secondary" toolbar, as "left" is not realy a name proper for any toolbar, but rather only a specification of its position at the screen. Regards, Dan On Dec 4, 2007 7:08 PM, Ray Benjamin <ray...@co...> wrote: > > > The menu items are inconsistent. I think I may have made a note of that > > somewhere, as well. I've just been looking at a few other Windows programs, > > to see how they handle View items that are turned on and off. Most of them > > just name the item. When it's on, a check mark is placed beside the item in > > the view menu. If we did this, the View Menu would be something like: > > > > Toolbar > > Left Toolbar > > ------------------------ > > Selection Rectangle > > Zoom In > > Zoom Out > > Zoom to Fit Page > > ----------------------- > > Note Window > > Attributes > > > > > Some applications use a sub-menu for the Zoom options. I think there are > > few enough they are fine where they are, but it might be useful to have > > icons associated with them, a magnifying glass with a plus sign for zoom in, > > and one with a minus sign for zoom out. This would help convey the meaning > > w/o translation. There doesn't seem to be an easily recognized icon for Zoom > > to Fit Page. Although, I could probably come up with something pretty > > easily. > > > > It might be helpful to have names for the two toolbars other than > > Toolbar and Left Toolbar. How about Main Toolbar and Icon Toolbar? > > > > Also, please put a check mark beside the options that are currently on. > > I know, in some cases, you can just look and see it's turned on, but it > > helps users if they get direct feedback on their actions. > > > > Ray > > > > > > Eric Lavarde wrote: > > > > Hi, > > > > toggle is not wrong, but it's in deed more difficult to understand, and > > also to translate. > > > > If it's about consistency, I'd suggest to rename the first one to > > "Show/Hide Selection Bubble" (or Rectangle, the Selection Bubble is not > > oval but rectangular with round corners, which would be a bit too long > > though ;-) ). As we already use "Bubble" in the Format menu for the same > > form, perhaps we should just keep the same name, or use everywhere > > "Rounded Rectangle". Bubble is fine with me, even though I've never seen > > a bubble of such a form :-) > > > > While we're at it: Menu Tools -> Preferences... -> Appearance -> > > "Selected Node Buble color" ==> Buble should be with 2 B's! > > > > Eric > > > > Dimitry Polivaev wrote: > > > > > > Hello, > > > > Dan has requested to change English menu items as follows: > > > > > > > > The following menu items are named inconsistently and should be renamed as > > follows:* View > Selection Bubble on/off > > **NEW: Toggle Selection Oval > > * View > Show/Hide Note Window > > **NEW: Toggle Note Window > > > > > > Because of my poor English i understand the old items, but can hardly > > understand the new ones. Could some people with good English validate > > the request, please. > > > > Dimitry > > > > > > -------------------------------------------------------------------------SF.Net email is sponsored by: The Future of Linux Business White Paper > > from Novell. From the desktop to the data center, Linux is going > > mainstream. Let it simplify your IT future.http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > _______________________________________________ > > Freemind-developer mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/freemind-developer > > > > > > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: The Future of Linux Business White Paper > > from Novell. From the desktop to the data center, Linux is going > > mainstream. Let it simplify your IT future. > > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > _______________________________________________ > > Freemind-developer mailing list > > Fre...@li... > > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > > > > |
From: Ray B. <ray...@co...> - 2008-01-07 22:19:51
|
It is always possible to make it a configurable option, but by doing so, we add another thing that can break. One reason I prefer the black check mark is that it is standard behavior for a Java widget that is used by millions. It's probably well-debugged. :) That's not to say it's wrong to add things that simply add to the style of a program, just that it's important to be aware of the price. Ray Christian Foltin (GMX) wrote: > Hi Dimitry, > > this is a question of taste, IMHO. I like to green marks more. > > Chris > > Dimitry Polivaev schrieb: >> Hello >>> please wait for the next checkin.. >> >> I think that the standard check marks from javax.swing.JCheckBoxMenuItem >> are better than the green OK - icon replacing the icon associated with >> an action. You can see the both types in the attached picture. As you >> see, the black check marks do not replace the action icons, so that it >> can be shown even if the menu item is marked as selected. >> >> So I propose to replace the JMenuItem by JCheckBoxMenuItem and not to >> use the green check mark in the menus. >> >> Dimitry >> >> ------------------------------------------------------------------------- >> >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Freemind-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemind-developer >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freemind-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemind-developer >> > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ------------------------------------------------------------------------ > > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > |
From: Ray B. <ray...@co...> - 2008-01-08 17:26:39
|
Reasamp, Welcome to the project. Your enthusiasm and energy are admirable. I'm glad you've chosen to work with us. I'm especially pleased that you are willing to jump right in to fixing problems you encounter. I'm Ray Benjamin, self-appointed project nit-picker and cheerleader. My background is in QA. Since I joined up, I've done more in the way of making suggestions and testing than code writing. Many of us on the project have to juggle a lot of responsibilities and other projects, so you'll get faster responses from some than others, when you post here. I'm using FreeMind to help me write a novel. For me, the writing has to come first. This is a pretty important time for this project. It looks like there may be some big changes made, going forward. We're trying hard to get the 0.9.0 release out the door. We're also looking forward towards the next release, and considering doing some major refactoring of the core code to make it easier to add new functionality to the program. --- From a QA standpoint, I don't think we should be allowing editing of the HTML, HEAD, or BODY tags in the note editor. As you point out, it's misleading. I propose that the proper solution to the problem is to hide those elements, if possible, in the note editor's HTML code view. If we want to allow the user to make document wide modifications to those elements, that probably should be done from an options or preferences menu selection using a pop-up menu. I don't think this problem warrants a fix in 0.9.0, since we're trying to get 0.9.0 out the door, but i do think it belongs in the next release. That's just my personal opinion. Others may have different ideas. Ray Reasamp wrote: > I'm not quites sure who here's working on it right now, so I'm posting it > here. > When I saw the HTML editor with long notes, impression was that every node > is a miniature HTML document and just naively I expected that if I make > changes inside <style> tags in <head>, it will make "nodewide" formatting > changes. Even seemed to work at first. The Layout view changed reflecting > my actions. But I click OK and all that change simply disappears. > > Now I have been able to track down the pieces of code involving this, that > was not the hard part. The thing is I just joined this list the other day, > so I don't really know what's the intended solution. I'd be glad to hear > of any options, but the ones I see are: > > 1) Allow <head> editing. But I'm not sure why this part of HTML was > repeatedly and intentionally wiped out in various parts of the code. Is it > to disable scripting? Or was it this exact problem that was being avoided? > > 2) Disable direct editing of <head> altogether. It would take quite a bit > of patching to allow user-mods in the <head> tag anyway. So one way to let > the user know that such changes are not supported might be to hide the > <head> part of the HTML code altogether, and show only <body>. Or to > somehow just disable editing of that part, but i'm not sure SimplyHTML > supports "disabling" part of the code from being edited. Don't have much > details on how SimplyHTML works. > > 3) "Node-wide" formatting is too small a scope to be troubled with this > "feature". But, a slight change of this behaviour could be considered nice > by some: the <head> part would be considered global across the entire map. > Anyone changes <head>, adds a new class for any tag, would effectively > change the head tag for every single node in the map. This would give such > <style> tags the same usefulness as their website counterparts. Not sure > if most ppl will consider it useful or confusing though. Could be used to > quickly apply a specific combination of formatting to a certain class of > nodes. > > Now I just need to know which direction is the intended one. Sorry for the > length of the mail. > > Reasamp > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > |
From: Dimitry P. <dpo...@gm...> - 2007-12-08 10:18:18
|
Hello, I am going to introduce the check marks for menu items Toolbar Left Toolbar Selection Rectangle Note Window If you miss something let me know. Dimitry |
From: Dan P. <dan...@gm...> - 2007-12-08 11:12:59
|
Hi Dimitry, a further menu item requiring chek mark is Menubar, in the popup menu of the map. The popup menu of the map has the following items, after renaming their titles: Menubar Toolbar (or Main Toolbar) Left Toolbar (or Icon Toolbar) Note Window. Thank you for the correction. Regards, Dan On Dec 8, 2007 11:17 AM, Dimitry Polivaev <dpo...@gm...> wrote: > Hello, > > I am going to introduce the check marks for menu items > > Toolbar > Left Toolbar > Selection Rectangle > Note Window > > If you miss something let me know. > > Dimitry > |
From: Dimitry P. <dpo...@gm...> - 2007-12-09 21:22:48
|
Hi, there is a problem with the note window: it is implemented as a plug-in, and information about the status of the note window is its internal information. I do not see how to install a listener communicating the note window status to the gui without changing the general plug-in framework design or introducing some bad hacks. IMHO the problem is coursed by the plug-in design: the main purpose of the plug-ins is introducing of the new user actions and gui elements. But there is no direct connection between gui elements and the plug-ins. In particular case of the NodeNote we have following call stack when the note window should be shown as a result of user action "Show/Hide Note Window": NodeNoteRegistration.showNotesPanel() line: 277 NodeNote.getSplitPaneToScreen(NodeNoteRegistration) line: 94 NodeNote.startupMapHook() line: 72 MindMapNodeModel(NodeAdapter).invokeHook(NodeHook) line: 818 NodeHookAction.invoke(MindMapNode, List, String) line: 177 NodeHookAction.addHook(MindMapNode, List, String) line: 97 NodeHookAction.invoke(MindMapNode, List) line: 138 NodeHookAction.actionPerformed(ActionEvent) line: 74 JMenuItem(AbstractButton).fireActionPerformed(ActionEvent) line: 1995 Let me explain: The action NodeHookAction is defined in the plug-in framework. It starts method "invokeHook" of the mind map. (which does not follow the swing convention where ActionListener becomes information about the origin of the event). The NodeNote object is stateless, it is created by the NodeHookAction every time the action is called. After creation its method startupMapHook() is called. Here it obtains the NodeNoteRegistration object created at the time of plug-in creation from the MindMapHookFactory (once for every opened map). The NodeNoteRegistration object is stateful, it controls the note window. And I do not know how to install a listener for communicating changes of this state to the gui elements without referencing internal plug-in classes not belonging to the plug-in interface. So I think that this indirect and not transparent logic should be better explained and documented and probably simplified in the 0.10.0. Chris can help us here, because he is likely to understand this design better than somebody else. But now I would like to ask you whether I should provide the checking mark for the rest menu items. Dimitry |
From: Dimitry P. <dpo...@gm...> - 2007-12-09 21:25:15
|
> But there is no direct connection between gui elements and the plug-ins. I mean that there is no direct connection between menu items and the plug-ins. Dimitry. |
From: Dan P. <dan...@gm...> - 2007-12-10 06:41:30
|
Hello Dimitry, I am not sure whether I understand properly what you are saying and what the main points are. I will try to formulate what I think I have understood. You are saying: For the action of hiding and showing of note window, with the current design of plugin interface, placing a check mark at the menu item is impossible to implement. The action that hides the note window has no way of finding out whether the note window is currently shown or hidden, so it cannot set the check mark properly. To enable placing the check mark at that menu item, the plugin interface would need to be extended. Is that right? Best regards, Dan |
From: Dimitry P. <dpo...@gm...> - 2007-12-10 07:12:48
|
> You are saying: For the action of hiding and showing of note window, > with the current design of plugin interface, placing a check mark at the > menu item is impossible to implement. The action that hides the note > window has no way of finding out whether the note window is currently > shown or hidden, so it cannot set the check mark properly. To enable > placing the check mark at that menu item, the plugin interface would > need to be extended. Correct. Dimitry |
From: Dan P. <dan...@gm...> - 2007-12-10 12:18:52
|
Hi Dimitry, maybe I am missing something. Is not it simply possible that the action "Note Window" remembers the state of the note windows? When the action hides the note window, the action sets its variable noteWindowShown to false, and vice versa. Would this solve the problem? Regards, Dan On Dec 10, 2007 8:12 AM, Dimitry Polivaev <dpo...@gm...> wrote: > > You are saying: For the action of hiding and showing of note window, > > with the current design of plugin interface, placing a check mark at the > > menu item is impossible to implement. The action that hides the note > > window has no way of finding out whether the note window is currently > > shown or hidden, so it cannot set the check mark properly. To enable > > placing the check mark at that menu item, the plugin interface would > > need to be extended. > > Correct. Dimitry > |
From: Dimitry P. <dpo...@gm...> - 2007-12-10 21:18:19
|
> maybe I am missing something. Is not it simply possible that the action > "Note Window" remembers the state of the note windows? When the action > hides the note window, the action sets its variable noteWindowShown to > false, and vice versa. Would this solve the problem? Hi Dan, I am afraid that this proposal can not solve the problem. It is is how to inform all relevant menu items (JCheckBoxMenuItem) with action show/hide note window always when the window is being displayed or hidden. The NodeHookAction is a standard framework action which knows nothing about the state or the meaning of the plug-in. Both the action and the menu item are created deeply inside the framework, and I do not see how to provide a connection between these parts without significant design changes or bad hacks. Further the plugin description should be extended so that JCheckBoxMenuItem is created instead of usual JMenuItem, but it is the less problem. Dimitry |
From: Dan P. <dan...@gm...> - 2007-12-11 09:16:02
|
Hi Dimitry and also Ray, given that providing the check mark for all the menu items would require some substantial design changes that you do not dare to perform, I would recommend the original proposal: Let all the items use the verb "to toggle" in their names, without check marks. Ray, do you have another proposal for the title of the menu items? Dimitry, do you think it better that all the related menu items should have check marks except for "Toggle Note Window"? I am quite unsure about what is the best. Elegance seems to speak for check marks even with one exception, consistency for no check marks. Best regards, Dan |
From: Dan P. <dan...@gm...> - 2007-12-11 09:20:01
|
Hello Chris, do you think you could help Dimitry to extend the HookNodeAction to enable showing of check mark in the menu item when the note window is shown? That would solve the problem, isn't it? Best regards, Dan |
From: Ray B. <ray...@co...> - 2007-12-11 11:23:40
|
I really think it's worth the extra bit of work to extend HookNodeAction. If not, I think it still makes sense to use check marks where possible, with the intention of fixing the Note window in the next release. Ray Dan Polansky wrote: > Hello Chris, > > do you think you could help Dimitry to extend the HookNodeAction to > enable showing of check mark in the menu item when the note window is > shown? That would solve the problem, isn't it? > > Best regards, > Dan > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ------------------------------------------------------------------------ > > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > |
From: Christian F. <chr...@gm...> - 2007-12-12 08:45:53
|
Hi, absolutely no time this week. Please wait before code changes: the check marks are already possible, you don't have to change the NodeHookAction AFAIK. But I can't understand that this issue is so important now. Can anybody explain this to me?? Chris -------- Original-Nachricht -------- > Datum: Tue, 11 Dec 2007 22:19:04 +0100 > Von: Eric Lavarde <fre...@zo...> > An: fre...@li... > Betreff: Re: [Freemind-developer] Toggle or not Toggle > I don't think it's worth hacking anything at this point in time: > straighten the menu entries so they all look similar (either toggle or > on/off or whatever), and add check marks for next release _everywhere_. > > Eric > > Ray Benjamin wrote: > > > > I really think it's worth the extra bit of work to extend > > HookNodeAction. If not, I think it still makes sense to use check marks > > where possible, with the intention of fixing the Note window in the next > > release. > > > > Ray > > > > Dan Polansky wrote: > >> Hello Chris, > >> > >> do you think you could help Dimitry to extend the HookNodeAction to > >> enable showing of check mark in the menu item when the note window is > >> shown? That would solve the problem, isn't it? > >> > >> Best regards, > >> Dan > >> > ------------------------------------------------------------------------ > >> > >> > ------------------------------------------------------------------------- > >> SF.Net email is sponsored by: > >> Check out the new SourceForge.net Marketplace. > >> It's the best place to buy or sell services for > >> just about anything Open Source. > >> http://sourceforge.net/services/buy/index.php > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Freemind-developer mailing list > >> Fre...@li... > >> https://lists.sourceforge.net/lists/listinfo/freemind-developer > >> > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > http://sourceforge.net/services/buy/index.php > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freemind-developer mailing list > > Fre...@li... > > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail |
From: Dimitry P. <dpo...@gm...> - 2007-12-16 23:12:07
|
Hello Chris, > absolutely no time this week. Please wait before code changes: the > check marks are already possible, you don't have to change the > NodeHookAction AFAIK. I am looking forward to your suggestions. Consider that only displaying the menu items with check marks is not a valid solution: 1. the check marks should also be properly initialized (shown or hidden), 2. if action is performed, the check marks should be shown or hidden again on all menu items carrying the action, independently from how the action is called. > But I can't understand that this issue is so > important now. Can anybody explain this to me?? IMHO Dan wants to have a professionally looking application, and I agree with him that checking marks are highly desirable to achieve this goal. Best regards, Dimitry |
From: Dan P. <dan...@gm...> - 2007-12-12 18:53:16
|
Hi Chris, I think this usability issue is important enough to be fixed in the final release version of 0.9.0. That said, the issue is not urgent. Regards, Dan |
From: Ray B. <ray...@co...> - 2007-12-13 22:39:28
|
I also think this is worth doing, if it can be done safely. If not, it's probably best to wait. I think reviewing the code is a good idea. As Dan has said, it's a usability issue, so it will make users that much more comfortable using FreeMind, but it's not going to make or break the release. As for the word "toggle," most native English speakers are familiar with this word. It just means something that turns things on and off, for example, a toggle switch. Take care, Ray Dan Polansky wrote: > Hi Chris, > > I think this usability issue is important enough to be fixed in the > final release version of 0.9.0. That said, the issue is not urgent. > > Regards, > Dan > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ------------------------------------------------------------------------ > > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > |
From: Dimitry P. <dpo...@gm...> - 2008-01-07 22:34:21
|
> this is a question of taste, IMHO. I like to green marks more. It is not only a matter of taste: the black check marks do not hide the own icon of the menu item. You see that there are facts speaking for them. And speaking about "the taste" IMHO the green mark looks not like a standard but like a toy. Dimitry |
From: Dan P. <dan...@gm...> - 2008-01-09 17:39:12
|
I think we should go for the professional looking black check marks. Dan |
From: Eric L. <fre...@zo...> - 2007-12-11 21:19:30
|
I don't think it's worth hacking anything at this point in time: straighten the menu entries so they all look similar (either toggle or on/off or whatever), and add check marks for next release _everywhere_. Eric Ray Benjamin wrote: > > I really think it's worth the extra bit of work to extend > HookNodeAction. If not, I think it still makes sense to use check marks > where possible, with the intention of fixing the Note window in the next > release. > > Ray > > Dan Polansky wrote: >> Hello Chris, >> >> do you think you could help Dimitry to extend the HookNodeAction to >> enable showing of check mark in the menu item when the note window is >> shown? That would solve the problem, isn't it? >> >> Best regards, >> Dan >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freemind-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemind-developer >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer |