networkmanagement plasmoid

Jan Grulich jgrulich at redhat.com
Fri Mar 29 11:41:18 UTC 2013


On 03/28/2013 04:43 PM, Aaron J. Seigo wrote:
> On Thursday, March 28, 2013 15:08:09 Jan Grulich wrote:
>>> * 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.
> Yes, it will certainly be more accurate. The average person only needs so much
> accuracy, however, to make a decision. The difference between 54% and 48%
> signal strength is probably not a huge issue in practice. :)
>
> The full strength could be shown in the details, of course. It just would be
> nice to see how minimal we can get the main UI and still be usable.
>
Which of these two would you prefer?
  -  http://www.imagehosting.cz/?v=nmugu.png
     or
  -  http://www.imagehosting.cz/?v=nm1.png
>>> * 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.
> aha .. That was not apparent. In the old NM applet, only configured connections
> were shown unless "Show more" was clicked. This was nice in that you only saw
> the APs that you already configured .. but had the overhead of another button.
>
> It's also an interesting question about usage: do people more often search by
> signal strength (maybe if they are in a public area looking to connect to a
> random AP?) or by AP name? or by open/secured status?
>   
>>> * 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.
> add this to your listview:
>
> 	clip:true
>
Fixed, thanks
>>> * 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
> ok.. fixed and pushed ...
>
>> *
>>
>>> * 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
> ok.. i fixed and pushed this too :)
>
Thanks
>>> * 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 new plasmoid you are working on now will eventually need to have the same
> X-KDE-PluginInfo-Name entry as the old one so that when installed it will
> automatically replace the old one.
>
> unless there is some reason NOT to do this?
>
>>> * 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)
> aaaaaawesome.
>
>> *
>>
>>> * 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
> what is needed is a way to switch between the current desktop editor and
> another one at runtime.. looking at the code, that apparently means
> Handler::editConnection and Handler::openEditor needs some modifications.
> Instead of running the desktop application, it will need to check the value of
> KDeclarative::componentsTarget() and then based on that decide what to run
> exactly.
>
> My biggest concern here is that in the editor all the business logic is
> coupled to the UI. I don't know if there is a better way of doing that, or if
> the simplest approach will indeed be to write a whole other configuration
> application with QML that can be installed next to the QWidget based one.
>
>>> * Activity awareness?
>> *no idea :) how would you want to integrate the plasmoid with the
>> activities?
> What would be fantastic is if one could set a given network connection to be
> started with a given activity. Use case:
>
> "Lisa works for Global Corp and uses a VPN to access the corporate network
> from outside the office. She does only wants the VPN activated when doing work
> related things, so she adds the VPN to her Work activity. Now, whenever she
> switches to Work, the VPN is automatically started along with having all of
> her documents and applications for work being available."
>
>>> 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?*
> They are all greyed out :(
This is weird, they should be greyed out only when this connection 
doesn't have uuid, which means that it's not configured. Could you 
please provide some debug output? You have to enable plasma-nm in 
kdebugdialog. Thanks

-- 
Jan Grulich
Red Hat Czech, s.r.o
jgrulich at redhat.com



More information about the Plasma-devel mailing list