Menu
▾
▴
wxmaxima-devel
|
From: Andrej V. <and...@gm...> - 2005-12-06 19:13:57
|
Hi all, Harald and I have been talking about some changes to the button panel under the input line. Something has to be changes since the space required for the panel in translated versions of wxMaxima is usually bigger than in the english version (sometimes it does not fit the screen). Rather than reducing the number of buttons, some other option might be better, which would allow for more functional panel. Using another library could be usefull (like wxDockIt from http://wxextended.sf.net/ ). If anyone else wants to participate in the discussion, please join in. Andrej ---------- Forwarded message ---------- From: Harald Geyer <Har...@gm...> Date: 6.12.2005 10:33 Subject: Re: wxmaxima (translation) issues To: Andrej Vodopivec <and...@gm...> Hi Andrej! > I have been thinking some more about this problem. Another option is > to use a notebook for the button panel. This way we can group buttons > for similar commands together in tabs (similar structure as in the > menus). This would allow for even more buttons - like constants, > common math functions and so on. Descriptive translations would be > appropriate with this solution. What do you think? I've been thinking about changes in the UI too. At some point I thought about making the buttons user configurable. I think generating the buttons dynamically shouldn't be much of a problem, but I'm not sure about the configuration feature (i.e. some possibility to drag menu items to the button area and set some custom lable) itself. Do you think that would be easy to implement? Also I'm not sure if the users needs vary enough to justify the additional burden... I think adding tabs would be a good idea, because they don't collapse after selecting an item as menus do. This would be especially handy if the user is experimenting without knowing yet which function suits his needs best. (At least I do that a lot.) However tabs need a lot of space themselves so they probably aren't very useful without reserving some extra space. Extra space of course makes the need for tabs less pressing ..= . An other benefit of tabs comes to my mind: If you ever plan to support additional maxima packages (like vect), the UI would already have a modular structure. But of course this is true for menus already. If we want the buttons in the tabs to remain fast accessible, then we propably shouldn't stick to much to the hierachic structure of the menu. Actually I think it would be useful to duplicate some of the buttons across some ot the tabs. However I'm not sure, which layout would be a good idea. I will try to observe my own usage habits more closely. Perhaps we should take this discussion to the public? If you agree, feel free to quote this message whereever you want. Harald |
|
From: Harald G. <Har...@gm...> - 2005-12-07 14:19:09
|
> av> So that we have an idea what tab based panel would look like I made > a > av> screenshot: > > av> http://wxmaxima.sourceforge.net/images/wxmaxima_with_tabs.png > > av> Nothing is decided yet - the changes are made so that we see the sp > ace > av> requirements. > > I don't like tabs.. in this case the user need an extra "click" > before he find the button.. Not really. If it is done right, then the user first selects the tab according to the problem he wants to solve and then (hopefully) all relevant features should be just there. Not sure if this can really be accomplished - thats part of the reason, why we brought this discussion to the public... > and also, increase the time needed > to find the button itself. As a user, I really preferr all items > there[1]. > > I don't know well wxwidgets[2]: is there the possibility to split > (automatically) on more lines widgets that do not fit on one > line? Gtk+ does (ex. Gimp: when you resize the window, the table > containing all the instruments changes shape). Also, still my > lack of knowledge of wxwidgets, probably it is possible to set > the buttons properties in order to allow label on multiple lines.. > > Btw, with Italian translation (in which most words are > truncated), I have no problems on debian gnu/linux with the > button widths. Yes. I triggred the current discussion, because I would prefer "Simplify radicals" over "Simplify (r)" for example. I think that the latter is bad UI design, because it neither tells the user what it is doing mathematically nor what it is doing from maxima's point of view. If we change to "Simplify radicals" that will consume to much space, so I think there are the following options: * Change to tabs * User literals maxima commands (i.e. "radcan") * Drop some less needed buttons - especially those which pop up dialogs * Make the buttons in some way user configurable, so that we don't need to figure out what's most sensible ourselves Regards, Harald |
|
From: Andrej V. <and...@gm...> - 2005-12-07 21:48:12
|
> * Change to tabs > * User literals maxima commands (i.e. "radcan") > * Drop some less needed buttons - especially those which pop up dialogs > * Make the buttons in some way user configurable, so that we don't need > to figure out what's most sensible ourselves I like the last option the most. Something like (multiple) palettes with different buttons on them which the user can have displayed or not. Displayed either as a separate floating window or docked in the main window. However current wxWidgets do not provide such functionality. We could use wxDockIt [1], which is a simple library for doing this, or wait for wxWidgets to provide this. I think wxIFM [2] will be integrated into wxWidgets for the next release. Andrej [1] http://wxextended.sourceforge.net/ [2] http://www.snakesoft.net/wxifm/ |
|
From: Andrej V. <and...@gm...> - 2005-12-07 21:39:34
|
> I don't know well wxwidgets[2]: is there the possibility to split
> (automatically) on more lines widgets that do not fit on one
> line? Gtk+ does (ex. Gimp: when you resize the window, the table
> containing all the instruments changes shape). Also, still my
> lack of knowledge of wxwidgets, probably it is possible to set
> the buttons properties in order to allow label on multiple lines.=
.
Splitting buttons into more than one line could be done, but if we
want to keep similar commands together that could be a lot of work.
However labels in multiple lines is a good idea. It works on windows.
Can someone test this on Linux? Replacing
button_3 =3D new wxButton(panel, button_radcan, _("Simplify (r)"));
with
button_3 =3D new wxButton(panel, button_radcan, _("Simplify\nradicals"));
in wxMaximaFrame.cpp should do it.
Andrej
|
|
From: Andrej V. <and...@gm...> - 2005-12-06 21:08:16
|
So that we have an idea what tab based panel would look like I made a screenshot: http://wxmaxima.sourceforge.net/images/wxmaxima_with_tabs.png Nothing is decided yet - the changes are made so that we see the space requirements. Andrej 2005/12/6, Andrej Vodopivec <and...@gm...>: > Hi all, > > Harald and I have been talking about some changes to the button panel > under the input line. Something has to be changes since the space > required for the panel in translated versions of wxMaxima is usually > bigger than in the english version (sometimes it does not fit the > screen). Rather than reducing the number of buttons, some other option > might be better, which would allow for more functional panel. Using > another library could be usefull (like wxDockIt from > http://wxextended.sf.net/ ). > > If anyone else wants to participate in the discussion, please join in. > > Andrej > > ---------- Forwarded message ---------- > From: Harald Geyer <Har...@gm...> > Date: 6.12.2005 10:33 > Subject: Re: wxmaxima (translation) issues > To: Andrej Vodopivec <and...@gm...> > > > Hi Andrej! > > > I have been thinking some more about this problem. Another option is > > to use a notebook for the button panel. This way we can group buttons > > for similar commands together in tabs (similar structure as in the > > menus). This would allow for even more buttons - like constants, > > common math functions and so on. Descriptive translations would be > > appropriate with this solution. What do you think? > > I've been thinking about changes in the UI too. At some point I thought > about making the buttons user configurable. I think generating the > buttons dynamically shouldn't be much of a problem, but I'm not sure > about the configuration feature (i.e. some possibility to drag menu > items to the button area and set some custom lable) itself. Do you > think that would be easy to implement? Also I'm not sure if the users > needs vary enough to justify the additional burden... > > I think adding tabs would be a good idea, because they don't collapse > after selecting an item as menus do. This would be especially handy if > the user is experimenting without knowing yet which function suits his > needs best. (At least I do that a lot.) However tabs need a lot of > space themselves so they probably aren't very useful without reserving so= me > extra space. Extra space of course makes the need for tabs less pressing = ... > > An other benefit of tabs comes to my mind: If you ever plan to support > additional maxima packages (like vect), the UI would already have a > modular structure. But of course this is true for menus already. > > If we want the buttons in the tabs to remain fast accessible, then we > propably shouldn't stick to much to the hierachic structure of the menu. > Actually I think it would be useful to duplicate some of the buttons > across some ot the tabs. However I'm not sure, which layout would be a > good idea. I will try to observe my own usage habits more closely. > > Perhaps we should take this discussion to the public? If you agree, feel > free to quote this message whereever you want. > > Harald > |
Thanks for helping keep SourceForge clean.
X