networkmanagement plasmoid

Thu Mar 28 14:08:09 UTC 2013

Hi,

these answers are from both :)

On 03/28/2013 01:56 PM, Aaron J. Seigo wrote:
> Hi Lukas and Jan,
>
> On Thursday, March 28, 2013 12:52:24 Lukáš Tinkl wrote:
>> we didn't initially think we could get
>> it in a usable state in such a short time ;)
> QML can be like that :)
>
> Lamarque is/was involved with this decision as well?
>
>> The current implementation uses only the new libnm-qt and libmm-qt (thin
>> wrappers around NM and MM libraries), making it far easier to add
>> features or simply keep pace with upstream NM/MM development.
> Does this also mean that systems without NetworkManager are not going to be
> supported?
>
> I don't know if people are still using wicd and similar very widely. At least
> we seem to have been able to get away from having to support connman for
> devices, which is nice.
>
*

*I*t seems (and lamarque could confirm) that NM is the only usable 
backend in the “old” plasmoid anyway

*
>> On the other hand, we definitely intend to reuse existing plasmoid's
>> code where it makes sense (VPN plugins, mobile broadband wizard, etc).
>>
>> So here we are, the code is in the plasma-nm git repo, we're looking
>> forward to your input :)
> There is some input I could offer right away (see below), but it's difficult to
> offer more right now without knowing what the design direction is.
>
> For instance, I'm unsure:
>
> * why there are long progress bars under each name while there is a static
> icon to the left that also visualizes a signal.
*

I thought it will look nicer than to have static icon. It's also more 
accurate.

*
> * if the connection icons to the right are intended to be the only mechanism
> to connect/disconnect
*

That's something we will have to change maybe, we are open to suggestions

*
> * which wireless routers you plan on showing in the menu by default.
> currently, all visible APs are shown (without sorting by name), but that could
> be just due to being in the early stages of development, or that could also be
> the intended result for final release. It's unclear if often used connections
> will be shown at the top, or if they will always be shown in the list with
> everything else that is visible. right now my machine can see 15 different APs,
> and that's not even a big number ...
>
> .. and similar. :) So anything you can provide as to the intended workflow
> would be very helpful as a starting point.
*

There are now all available connections and APs, but they are sorted by 
those keys - connected, connection type, configured connection and APs 
are sorted by signal strenght.

*
>
> Things I can observe right away:
>
> * The list of items goes under the translucent status bar at the bottom of the
> window. This looks very messy and makes it hard to see what's going on. Might
> be better to make the status bar opaque .. or have you tried that already?
>
> * Mouse events go through the status bar to the item underneath .. so clicking
> just to the right or left of "Connected" will open the details for the item
> shown under it.
*

That's a problem with ListView, it has anchors.bottom: statusBar.top but 
it doesn't work properly. I didn't find any better solution.

*
> * In the metadata.desktop the description is reeeaaally long (making it
> unusable in the system tray dialog) and includes lots of jargon. Would you
> mind if I just went in there and cleaned it up according to our usual
> guidelines?
*we will try to come with something better, we don’t mind if you just 
improve it :)
*
> * When the popup closes, the UI does not reset .. so when I close and later
> re-open the popup instead of being at the starting point, I'm where ever I was
> when I last used it.
Ok, *I’ll fix it
*
> * why is there a makedata.desktop.cmake?
*

I was inspired by KTP, they have also metadata.desktop.cmake and in 
CMakeLists.txt they are using
  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/declarative//metadata.desktop.cmake

${CMAKE_CURRENT_BINARY_DIR}/declarative/metadata.desktop

                         @ONLY)

*
>
> Topics for discussions regarding integration with existing systems to make for
> an acceptable upgrade experience:
>
> * This plasmoid needs to work flawlessly with touch as well as mouse/keyboard.
> Fortunately, we can provide touch customizations of QML and Javascript files in
> the package (by placing such things in platformcontents/touch/ where they will
> override what is in contents/). Main issues here will revolve around the size
> of active press areas: the connection buttons, the configure buttons. This
> could easily be addressed by making some tweaks such as: an easily pressable
> button that appears in the details area for connecting/disconnecting, and
> making it so that pressing anywhere on the status bar opens up the
> configuration options area.
>
> * The name of the component must end up being the same as the current nm
> plasmoid, otherwise we will need to ship an update script and that seems
> unecessary.
*you mean the “old” widget based one or the newer QML applet?
*
> * The usage graphs are not implemented in the new widget; seems they would fit
> in very nicely in the details widget though?
*

Yes, we can add it later

*
>
> Topics for discussion regarding on how we can improve over the old plasmoid:
>
> * When connecting to a new wifi access point, it throws up the big scary full
> configuration dialog when all one needs 99% of the time is to put in a
> password. Being able to jump from a simple password dialog to the full dialog
> would obviously be needed .. but would probably increase user friendlineses a
> lot
*that’s what we currently do, we just ask for the password for 
unconfigured connections (without the clumsy config dialog, as seen in 
the old applet)
*
> * On touch devices, the dialogs which are perfect for managing connections
> with the mouse and keyboard are not so perfect. :) Have you thought about ways
> to allow form-factor specific UI for the connection management UI? We'd
> probably want to do this in QML as well .. and we can tell what the current
> runtime environment is from KDeclarative easily enough .. so we just need
> integration points in the new code to swap between different connection
> management UIs (though using the same backend code one hopes ...)
*

help is certainly welcome here, we don’t have any such devices to test 
our applet on

*
> * The current plasmoid shows a not-so-helpful "map" view when it scans for new
> access points, and this is available only from the Add connection drop down.
> If this could be streamlined and made simpler, it would be great.
*weird, I never found out this feature before, first time hearing of it :)
*
> * Activity awareness?
*no idea :) how would you want to integrate the plasmoid with the 
activities?
*
>
> What I really like already:
>
> * What is there right now is clean and simple. Hooray for increased elegance.
>
> * What is there generally seems to work
>
> For whatever reason, I can't actually add or edit anything that is shown, but
> I'm guessing that's a problem with my local installation / configuration. If
> you have any hints as to how to unlock that achievement, I'd appreciate it.
> (I'm running nm 0.9.8 fwiw)
*Are you unable to click on the edit button when you display connection 
details? Or this button is greyed out?*
> Thanks for your work on this .. I hope I haven't deluged you with feedback
> here :)
*not at all, we certainly value any input/feedback we might get
*
>
-- 
Jan Grulich
Red Hat Czech, s.r.o
jgrulich at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130328/4a30b599/attachment-0001.html>