Version: 1.2.0_devel (using KDE 3.4.0, compiled sources) Compiler: gcc version 3.4.3 OS: SunOS (sun4u) release 5.8 When dealing with data files containing large amounts of variables (we routinely have 2000 to 8000 variables !), it is sometimes difficult to keep track of what is currently selected. A means to do that would be very helpful, though I don't exactly know how it should be implemented, but here are a few suggestions: - button bringing up a popup dialog with the list ? - button to clear the list temporarily and display only selected vectors ? - keep them at the top of the list in all circumstances (not my favorite, because it would get in the way of the cool filter feature) ? - other ? Note that it would be nice to also have the total number displayed somewhere, possibly in a label below the list (e.g. "[x] variables selected out of [n]").
One possiblity would be to add an additional column to the list control which would be titled Checked. The entries for this column would read Yes or No (or possibly blank). This would allow the user to sort based on this column - allowing the user to quickly determine which fields have been included for plotting. If that sounds acceptable I'll go ahead and implement it.
On Wednesday 18 January 2006 14:45, Andrew Walker wrote: > ------- One possiblity would be to add an additional column to the list > control which would be titled Checked. The entries for this column would > read Yes or No (or possibly blank). This would allow the user to sort based > on this column - allowing the user to quickly determine which fields have > been included for plotting. > > If that sounds acceptable I'll go ahead and implement it. Should be fine, but only after 1.2.0 goes out.
Alternatively we could use Available and Selected lists, which addresses both this bug report and also 120329.
The only problem with Available/Selected lists here is space (it will make the dialog even wider, and it is already pretty wide)... Otherwise, it could work pretty well (certainly nicer than what is there now). If we can keep the dialog within 800x600, I think this is the way to go. We need to keep the search box etc though.
I think the Search Box would continue to act on the Available list. The Check Selected button would have to change its name - and would simply move the selected items in the Available list to the Selected list. Other than that I think things would stay pretty much the same. Real estate could be a problem, but there's probably ways to shuffle things around to fit it all in. The only drawback I see is that for the simple case (e.g. selecting two fields out of some small number) the user goes from two mouse-clicks to either two mouse double-clicks (double-clicking moves from the Available to Selected), three mouse-clicks (two to select the fields and one to move them), or two drag-and-drop operations. Any way you do it it will take longer than it used to.
On Thursday 19 January 2006 13:44, netterfield@astro.utoronto.ca wrote: > 19:44 ------- The only problem with Available/Selected lists here is space > (it will make the dialog even wider, and it is already pretty wide)... > Otherwise, it could work pretty well (certainly nicer than what is there > now). If we can keep the dialog within 800x600, I think this is the way to > go. We need to keep the search box etc though. I agree.
I'd say that the available/selected approach is better in the long run, but in the short term we could live with the extra column. The extra clicks sound acceptable to me considering the improvements they buy. As for real estate, it seems clear that we'd need to move the other options to another page, but I'm pretty sure we could find a way to fit all that into 800x600.
Should be fixed for 1.2.1 release
Created attachment 15137 [details] Proposed UI Shows the proposed UI if we go for the ability to select the field/column order. I'm not convinced the extra real-estate used is really worth it, given the fairly meagre return. If we don't go this route then we could simply addd the extra column to the existing list widget.
Looks good to me :-) I think we should try it like this and get some user feedback as to whether they like it better this way, but I'm quite confident. Since this is a *highly interesting* topic, I can't resist the temptation to make a few remarks: - what does the reset button do ? If it clears the "selected" list I think it should be on the left side (e.g. below up and down) and called "Clear list" - to move the curves around, drag&drop might be better than (or a nice complement to) the "up" and "down" buttons - it is important to preserve the ability to sort available vars both alphabetically and in the order they are provided by the datasource ("position"). But I suppose that's how it's planned anyway... - one more complicated (but IMHO really interesting) feature we could offer is a way to groups curves at this stage in the "selected" listview, like I did in gaiw. This would make the "Curve placement" groupbox useless in the last page, but offer much more flexibility. The advantage of this is that it's much faster to do it here than changing plot contents one by one in the plot dialog later on. Note that there is something we need to discuss further here: do we initialize the list with the current list of plots and their curves, or only allow to add new plots ? The latter is certainly easier but could lead to consistency problems when the wizard in invoked when there already are curves. Anf finally, there is also the question of multiple windows (but we could handle that either with tabs or by just showing the current window). I will attach a screenshot of how gaiw does this (for just one window, it has no notion of multiple windows as xmgrace does not support this) to make it clearer... - a label below the selected curves like "Selection: x curves out of y possible" would be very nice. If we implement the above "grouping" proposal it could be "x/y curves in z plots"... - to make this completely consistent, this is the page where it would be appropriate to have the "regrid" button since this is where you see how many plots you'll have in the end. Column break markers in the list could be nice as well... Even though this may seem to make the datawizard more complicated for the user(which is true to some extent) I think the overwall workflow is much better. When you want to plot curves and arrange them other than 1 per plot or in a given order, the current situation is that you load the curves with the datawizard (probably 1 per plot), then go to each plot, call up the dialog, change the contents, apply, move on to the next one, etc. At the end, you also have to relayout the whole thing to arrange the columns in a reasonable way so that e.g. all curves pertaining to the roll axis (just an example :-)) are in the same column, and finally you remove plots you no longer need. All this could be done much faster in the wizard if we implement the advanced selection/grouping features. Sorry for being so long, but I think this is really important, at least for users working a lot with the datawizard, and would contribute greatly to making kst even more productive (I get complaints about the lack of these "organization" features regularly).
Created attachment 15144 [details] Screenshot of a gaiw session Notes: - there is no multi-window concept in gaiw, it needs to be discussed how this could be added - the multi-selection mode ("extended selection" mode in QListView) is very useful (for some reason kst does not have the same) - the buttons between available and selected lists have the following use (from top to bottom): 1) add all selected vars to the currently selected graph (plot) or a new one is there is no graph selected ; 2) add selected vars one per graph (see tooltip) ; 3) add selected vars to a single new plot ; 4) add a column break (nice but adds to code complexity !) Don't hesitate to ask me for more information if that's unclear...
Should we go this route I think this approach should only be made visible to the user if they request it. For a typical user the wizard is most likely used to create one or two plots - and they would not like to be confronted with the bewildering array of lists and buttons that this enhancement would require. We should probablt also consider a plot manager which would allow the user to move plots between windows and quickly change multiple settings.
Andrew's dialog looks good. -I assume multi-selection will work in either box, as before. -"alt <" and "alt >" should be added as keyboard accelerators. -On entering the page, the cursor/focus should be in the search box. These two steps will allow fast keyboard only selection in the common case (eg "*GYRO*alt<altn" selects the gyro channels and moves us to the next page. So we only lose 1 key stroke (altn) compared to the current implementation. To create multiple plots with differing contents, enter the wizard for each plot. With the 'remember stuff' patch Andrew just put in, this should be pretty easy. I agree with Andrew that a data-object manager will be a good idea - a bug should be opened on it.
The UI generally looks good, but it should probably mimic other related UIs which have the up,down,left,right oriented as a compass. We should probably also keep the "available data" on the left and the "data to load" on the right. Workflow is typically left->right. The actual .ui file seems broken according to my ui viewer. Some widgets are missing layouts. Better test it before committing (including for tab order).
SVN commit 521222 by arwalker: BUG:120330 Major feature implemented. The UI is designed to mimic the plot dialog curve selection as much as possible for consistency in UI design. If there are any additional features desired please submit a new bug report. M +94 -86 datawizard.ui M +7 -2 kstdatawizard_i.cpp M +23 -17 kstdatawizard_i.h
Reopened until the patch is fixed.
What's the status on that one after the ui.h vs deriving discussion and the revert/unrevert/re-re-un-revert/... sequence ?
SVN commit 528439 by staikos: two patches that I'm stuck committing together: 1) remove KstPoint and make the two functions namespaced (KstCurvePointSymbol) 2) merge back the DataWizard patch by Andrew, with a few bugs fixed and a few bugs added (UI related) We decided not to keep the x/y selected label. BUG: 120329, 120330 M +0 -2 extensions/js/bind_point.h M +435 -169 libkstapp/datawizard.ui M +265 -189 libkstapp/datawizard.ui.h M +3 -3 libkstapp/kstcurvedialog_i.cpp M +1 -1 libkstapp/kstcurvedifferentiate_i.cpp M +1 -1 libkstapp/ksteqdialog_i.cpp M +1 -1 libkstapp/kstfilterdialog_i.cpp M +1 -1 libkstapp/kstfitdialog_i.cpp M +1 -1 libkstapp/ksthsdialog_i.cpp M +1 -1 libkstapp/kstpsddialog_i.cpp M +1 -1 libkstmath/Makefile.am A libkstmath/kstcurvepointsymbol.cpp libkstmath/kstpoint.cpp#526781 [License: GPL (v2+)] A libkstmath/kstcurvepointsymbol.h libkstmath/kstpoint.h#526781 [License: GPL (v2+)] D libkstmath/kstpoint.cpp D libkstmath/kstpoint.h M +13 -15 libkstmath/kstvcurve.cpp M +4 -4 libkstmath/kstvcurve.h M +1 -1 widgets/curveappearancewidget.ui M +3 -8 widgets/curveappearancewidget.ui.h M +1 -1 widgets/datarangewidget.ui