Totally agree on the problem and as well with the suggestion of
providing an activity indicator to show that nothing crashed, behaves
strange or does something else unwanted, but just needs more time :)
Thanks Aaron for summarizing the usability problem(s) around the current
state.
Jan
Am 03.02.
Am 02.02.2016 um 19:14 schrieb Thomas Friedrichsmeier:
> On Tue, 2 Feb 2016 14:48:16 + (UTC)
> Jan Wort wrote:
>>> Please test the git branch work/preview_with_menu . What I did was:
>>>
[…]
> OTOH, that would put the buttons in the middle, which also seems kind of
> strange to me.
>
> Or pla
Hi,
> while we're still at brainstorming, I'll toss in a further thought
> in this category: Turn the "Preview"-checkbox itself into a tri-state
> control, e.g. a drop-down menu "Preview disabled", "Docked Preview",
> "Separate window".[…]
What I know as a sort of standard from dockable windows i
> Can you think of any use-case where this would _not_ be desirable?
Did just a brief check so far; the interface seems to be fine :)
I'll keep my eyes open for edgecases though.
Jan
Am 29.01.2016 um 12:03 schrieb Thomas Friedrichsmeier:
> Hi once more,
>
> On Tue, 26 Jan 2016 07:13:47 +
Am 01.01.2016 um 22:07 schrieb Thomas Friedrichsmeier:
> On Fri, 1 Jan 2016 21:41:49 +0100
> d_jan wrote:
>
>
> I had thought about tabs, too, a bit. But how do you hide all previews?
If none of the checkboxes are checked, no preview or code is shown. If
one is checked, one tab
Am 30.12.2015 um 11:37 schrieb Thomas Friedrichsmeier:
[SNIP]
>> Like this:
>>
>> Preview__â__
>> Code_â__
>
> [SNIP] What bugs me in this approach, is that
>
> 1) [â¦] > essentially a bit of a waste of space.
Yes. One could restructure other parts of the
Hi Thomas,
I had a look at the new function/plugin as well as at the different
preview possibilities.
> The "usual" placement would be at the bottom of the dialog
Yes, this would be my preferred option usability-wise too.
Also, the current implementation is not bad for previewing the import
(or
I tried to incorporate the needs outlined by you in a (hopefully) usable
design, which I visualized and described at
https://community.kde.org/RKWard#Plotting_issues_of_various_kinds
Have a look if it makes sense and/or if you have any questions
Colors, fonts etc. are on a very sketchy level, so
Hi,
TL;DR:
0) Unambigous (not-delete-like looking) symbol for warning: good.
1) Don’t allow adding certainly wrong values in the first place
2) In a likely-to-work scenario, warn users in a comprehensible way.
2.2) If the likelyness is rather low or a wrong input causes certain
mayhem, stick with
Hello,
Version: current master (ca. 10:00, 20th of November)
In several Plugins I can’t execute tests etc. since the submit button is
not activated.
Steps to reproduce the bug:
1) Load Orange Dataset (e.g. I did orange <- Orange)
2) In the Chi Squared Test for outlier, select the orange age vari
Am 18.11.2015 um 13:17 schrieb Thomas Friedrichsmeier via KDE Bugzilla:
[SNIP]
>
> a while ago, we were discussing the possible inclusion of the graphics
> devices
> somewhere into the main window of RKWard, instead of (or in addition to)
> opening it in a separate window.
Is "opening in a sep
Hello RKWard Devs,
While thinking about the graphic "[rkward-devel] [rkward] [Bug 355533]
New: Graphics devices tool window [draft]" and creating some graphics, I
noted that the dot chart plugin has the contraintuitive ordering of UI
elements – the essential variable slot of the variable picker is
xp (or read
>the tooltip).
>
> Please test and let me know of any quirks.
>
> Regards
> Thomas
>
> On Fri, 13 Nov 2015 21:25:10 +0100
> Thomas Friedrichsmeier
> wrote:
>
>> Hi,
>>
>> On Fri, 13 Nov 2015 11:08:08 +0100
>> d_jan wrote
Am 13.11.2015 um 13:15 schrieb meik michalke:
> however, this seems to make it impossible to actually use regular expressions
> at all -- this should probably be configurable in the extended options
> ("match
> text" vs. "match regular expression")
I’m unsure about the regex feature – can you
Am 06.11.2015 um 13:18 schrieb d_jan:
> Hi,
>
> ok, so I have now pushed the first "complete" draft of the Workspace
> browser including search functionality into git master. (I'm sure you'll
> find some details to improve, though).
uh, really neat!
I wa
Am 06.11.2015 um 13:47 schrieb Thomas Friedrichsmeier:
> On Fri, 6 Nov 2015 13:18:43 +0100
> d_jan wrote:
>>> For "Show all Environments":
>>> - remove the option from the "main" UI
>>> - keep it in the context menu
>>> - change the
Am 06.11.2015 um 11:12 schrieb Thomas Friedrichsmeier:
>>
>> /It organizes the workspace in two groups, the "My Data" or "My
>> Workspace" which groups all user created objects and data (globalEnv)
>> and the "other Environments".
> that part is now ready for you to look at. I moved the expand / c
Hi,
I’m undecided on the zebra-striping of the table, both look good to me.
Talking about good: I think we archived a major improvement in the
usability here in terms of using the users existing knowlege, allowing
the view of details and context and avoiding seperate GUIs for editing
and viewing.
Hi Thomas,
> Splitting this into a new thread to make it easier to follow. I have
> now merged the optionset UI rework into "master"
great!
>> - Klicking on the + only would be…
oops. some characters got lost. anyway, it has low priority I think; it
were some thoughts on the interaction to ope
Am 05.06.2015 um 20:58 schrieb Thomas Friedrichsmeier:
> Hi,
>
> On Fri, 05 Jun 2015 12:41:22 +0200
> d_jan wrote:
> [...]
>> ah, good to know. I came across the quoting/non-quoting stuff as well,
>> in my case in terms of usability (it is probably an instance the
&
Hi RKWard Devs,
(Scroll way down for summary)
Am 04.06.2015 um 20:10 schrieb Thomas Friedrichsmeier:
> On Wed, 3 Jun 2015 17:57:36 + (UTC)
> Jan Wort wrote:
>> [SNIP] …
>> related to
>> the GUI connected to otionset and not only a problem of the optionset
>> control alone.
>>
>> E.g. the r
Hello RKWard Devs,
While I was on it, I put some not-so-discussion-prone bugs and proposed
fixes in the wiki (+Screenshots) – https://community.kde.org/RKWard.
Part of it builds on Abattys suggestions:
- Data Import. Suggestion: "Import Data" is error prone, submenu seems
to provide same function
Am 02.06.2015 um 13:52 schrieb Thomas Friedrichsmeier:
[…snip…]
>
> Small hint, on following the bleeding edge development, easily: This PPA
> provides daily builds for Ubuntu, i.e. should have the buttons by
> tomorrow:
> https://launchpad.net/~rkward-devel/+archive/ubuntu/rkward-dailys
>
Than
Hello RKWard List,
Since I am able to program Javascript and to be involved in a part of
RKWard where I am likely to contribute (at least) parts of the code
myself I had a closer look at the plugins and how they are programmed.
I came across the GUI element since it is used in some
plugins I use
Hi Meik,
Just in case you did not read the long-ish mail I send yesterday: In
regards to the locking issue I would propose a checkbox or two
lock|unlock buttons in the toolbar: It is immediately visible und
understandable of the user.
The defaults should be kept like you say imho.
Regards,
Jan
Am 26.05.2015 um 15:10 schrieb Thomas Friedrichsmeier:
TLDR: Locking should be a checkbox or 2 buttons; separator issue was
added to the wiki; cover usecases for data/packages by two
sidebar-windows: 1. data, 2. the whole, "real", R Environment (both can
share the same code, is is more a matter is
Am 22.05.2015 um 17:35 schrieb Jan Wort:
> Hi,
>
>Issue 1: Deleting data
>
>> It should be very, very obvious, how to switch from read-only to
>> editable and back. […] Probably a KMessageWidget shown…
>
> What about utilizing the top toolbar? It already adapts to the type of data,
> and for
27 matches
Mail list logo
