Review Request 124133: Add dedicated Version tab to KAboutApplicationDialog

Lamarque Souza lamarque at kde.org
Tue Jun 30 11:45:35 UTC 2015



> On June 20, 2015, 7:10 p.m., Martin Klapetek wrote:
> > +1 for adding all that info
> > -1 for putting it into its own tab; previously it was visible right away, now an additional click is needed. Maybe it could be stacked all under the application name? I mean it's just 2 more lines to add there...
> 
> Sebastian Kügler wrote:
>     Putting more and more versions there doesn't scale. Just cramming more and more stuff in there doesn't really make it more beautiful, putting it into its own tab means that the information is neatly organized.
>     
>     Also, the version is really an implementation detail, and having one version there will often yield another round of asking ("Which versions are you running? - "version x.y.z" - "No, I need the versions that are shown in the tab, so also frameworks, Qt, and whether it runs on wayland or X11."
> 
> Martin Klapetek wrote:
>     Honestly the only time I've seen/told anyone open that dialog was to get the app version number. This was previously visible right away, now it's hidden in an additional click. Could perhaps be at least made the first/default tab?
>     
>     "and having one version there will often yield another round of asking"
>     
>     I'm not sure I understand what you're getting at, but given there was only one version string in that dialog for longlonglong time, I've never hit the scenairo you're describing. My idea was to do this:
>     
>     KWrite
>     ======
>     Version 5.0.0
>     Using KDE Frameworks 5.12.0
>     Qt 5.4.2 (built against 5.4.2); xcb/wayland
>     
>     ...ie. just add one more line below the current data set in the main layout and have no version tab at all; all the data visible right away after opening the dialog. It doesn't need to scale as there are no more version numbers to put there (unless we want to put everything in there).
> 
> Martin Gräßlin wrote:
>     one of the thoughts was also to give applications a possibility to easily add more information about it. E.g. in KWin the supportInformation (we don't have an about dialog) there are about 10 individual version/compile information put out. So while you didn't have the need yet, I experienced this need in the past a lot.
>     
>     Concerning first tab: not sure. Is this the most important information? And even if: do users count the clicks? I doubt it.
> 
> Alexander Potashev wrote:
>     If there will be 10 versions in the main tab, it is still not a problem because we can make the view scrollable.
> 
> Martin Klapetek wrote:
>     "Is this the most important information?"
>     
>     I'd like to think it is. You rarely need any of the other information - whenever a user reports a bug without a version number, first thing he's asked is "what is the version you're running?". Users may look at authors, but surely not repeatedly or at least not the same amount as looking for version string. In my humble opinion, for us developers and bug triagers, the version number is the most important information in that dialog and as such should be as quickly and easily accessible as possible.
>     
>     This patch moves away this vital piece of information from first glance into a separate non-default tab. That does not seem like an improvement to the situation.
>     
>     I bet that if you'd ask any random KDE software user what is in that dialog, they would most probably not be sure beyond the version number (which should hint at what is actually most important/used information).
> 
> Martin Gräßlin wrote:
>     I hope that more application maintainers provide their thoughts on it. After checking quite some applications I can only conclude that version numbers in the KDE Applications are not maintained, incorrect and wrong. Given that I don't think we do our applications a favor to expose the version number that prominent in a first tab.

This is a +1 from me. I agree that this change makes about dialog cleaner. I do not appose to it although every time I have asked an user to open an about dialog I did it so that the user could send me the version string. Adding one more click does not help here but also does not prevent the user from reaching it. What our usability experts have to say about this change?


- Lamarque


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124133/#review81603
-----------------------------------------------------------


On June 20, 2015, 4:30 a.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124133/
> -----------------------------------------------------------
> 
> (Updated June 20, 2015, 4:30 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> -------
> 
> This replaces the version information of the version and frameworks and
> moves it into a dedicated tab. In this tab the information is extended
> by the Qt version (which is equally relevant as e.g. the frameworks
> version) in both runtime and compile time.
> 
> Also windowing system is added. This will become a useful information
> for KWin developers starting in Plasma 5.4 when users start to test
> things out and we need to know whether the window they experience the
> problem with is running on wayland or xwayland.
> 
> 
> Diffs
> -----
> 
>   src/kaboutapplicationdialog.cpp 5eeea7711aa4f95a9cd4191d68ad330ef795caea 
> 
> Diff: https://git.reviewboard.kde.org/r/124133/diff/
> 
> 
> Testing
> -------
> 
> 
> File Attachments
> ----------------
> 
> New wayland, new X11, old X11
>   https://git.reviewboard.kde.org/media/uploaded/files/2015/06/20/b76ba6ae-b01c-4c6a-9248-29d39c652d83__snapshot_J11265.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150630/2db87c97/attachment.html>


More information about the Kde-frameworks-devel mailing list