Re: krdc ui, looking for suggestions

On Saturday 11 July 2009 15:28:15 Tony Murray wrote:

> Ok, two points that I haven't said.  The connection input field
> will always stay in the toolbar area, there is no reason to hide it
> on a tab or the "home page". 

Actually there is -- you said it yourself, space :-) Besides, general 
behaviour of KDE apps should be the same. Currently editbox and the 
buttons are separate things, normally UI design looks like this
[ value ] [ action ]

(in short: they are visually related, close -- not always that 
close -- together) 

So I would really opt for bringing editbox down, to start page, near 
_one_ button "connect".

> The buttons that say connect to vnc 
> or rdp just focus the input field and pre-select the protocol. 
> (This is how they function now, so no changes)

I already reported (after your initial post, I started testing krdc a 
bit) that this leads to problems -- you select rdp, you enter vnc 
address, you click on "rdp connect". This is too confusing.
Look at the Konqueror -- it handles, http, https, ftp. It does not 
have any preselector, and it does not have 3 buttons -- http connect, 
https connect, ftp connect. Simply "connect".

I suggest to quit both (preselectors and several connect buttons) and 
just keep URL and connect button (like in Michael mockup). If there 
is no protocol entered, you could:
a) start from default one
b) and probe sequentially the rest (until success)

This way, user would not even have to know about protocols (actually 
it is my case "what rdp protocol? I just have krfb running on 
server" :-D).

> The reason I changed the Bookmarks/History/Browse to a slider
> (QToolBox) is I think it might be a good idea to have an option to
> show the same widget in a dockwidget that can be put in the side as
> an option.

This part I didn't understand -- the only difference between slides 
and tabbar is how they are visually organized. The content is the 
same, and you can only see one entry (slide or tab).

However slides require extensive mouse movement (more arguments 
against in the previous thread).

Cheers,
_______________________________________________
kde-usability mailing list
kde-usability@xxxxxxx
https://mail.kde.org/mailman/listinfo/kde-usability