Registered Member
|
I recently came across this video: https://www.youtube.com/watch?v=N7-fZJaJUv8
Did anybody fromthe GUI team have a look? |
Registered Member
|
Welcome to the forums!
There are bugs that are tracked individually, see the description of the video. However that behavior has nothing todo with a "GUI" whatsoever, its simply the logic implemented (I mean, yes, some tooltips are wrong and notifications appear that shouldn't etc. but that is more wrong behavior than a graphical user interface bug). I hope this answers the question and closes this thread, because I cannot see what this has to do with this subforum whatsoever. We have a bugtracker for tracking progress of bugs, we have irc to ask around, but a forum is not the best place to ask one simple question imho, especially since developers usually hang around somewhere else and you will reach developers easier by using the bug tracker or on irc. Other than that I fully agree with you that some of this is really annoying and should be fixed. |
Registered Member
|
I think that while his use of the terms GUI and GUI team may be a little inaccurate (more accurate would be UX and design group), but by no means is this the wrong place to post his suggestions.
I see the mentioned items as a collection of design flaws/deficiencies and he expects that the design forum would be a good place to start so that we can collaborate on what changes should be made to ensure the best experience for the end user. A good place to start would be to enumerate the items mentioned from the video and get to work.
airdrik, proud to be a member of KDE forums since 2008-Dec.
|
Registered Member
|
Imho most those are unhandled corner issues, nothing I would consider a design issue. Someone is needed to step up and fix those. Discussing them is good, fixing them is better. Example: When you create a new file in Dophin, the respective file you create new is copied from a template location and renamed to whatever you specified. This means internally this is handled as an copy operation. Now currently if something goes wrong it says something about a copy, while the user will be confused because he did not copy something according to his knowledge. All these special cases would have to be handled separately in the code. Another issues are the notifications: All the cases should be handled correctly. That requires someone to do quite some work and I can understand that this kind of bug fixing is rather boring and the fun factor is pretty low. It is actually really dirty work digging for all this code areas and handle the cases. For the enumerating things part: The creator of the video did this already: https://bugs.kde.org/show_bug.cgi?id=332456 https://bugs.kde.org/show_bug.cgi?id=332457 https://bugs.kde.org/show_bug.cgi?id=332458 https://bugs.kde.org/show_bug.cgi?id=332459 https://bugs.kde.org/show_bug.cgi?id=332460 https://bugs.kde.org/show_bug.cgi?id=332461 https://bugs.kde.org/show_bug.cgi?id=332462 https://bugs.kde.org/show_bug.cgi?id=332463 https://bugs.kde.org/show_bug.cgi?id=332464 https://bugs.kde.org/show_bug.cgi?id=332465 https://bugs.kde.org/show_bug.cgi?id=332466 |
|
"All issues" in the video have been filed as bugs to the relevant components, perform an advanced bug search for URL containing "fZJaJUv8"
And that video is ridiculously exaggerated. Seriously. |
KDE Developer
|
Best way to help, quickly go through each of those bug reports on plasma5 and see if they are all still relevant. |
Registered Member
|
It's all from the mac os user point of view. It's a bit exaggerated but has some truth in it. If design guys aim to make this DE experience more user friendly it's wise to take notes from Mac. The video shows who designed those notifications: developer. And who can blame them? They are technical guys. They use computers differently. For example right now on KDE 4.14 if you have a samba share and want to browse photos with gwenview from it you have to deal with new notification called copying everytime you click "next picture". It \s technicaly correct because it's being copied to tmp folder and then viewed from there. But who cares about that? Idk keep those progress bars in gwenview as it's so annoying to see notification pop up everytime. It's all small things that matter maybe not the most, but a large amount. |
Registered Member
|
Well it's room here for anyone who wants to dig into these bugs and look into everyone of them and suggest ideas. As we all know - its not just a question of saying "Ok everyone stop what you're doing and do this" - its not how it works and we're kinda drowning in work as it is.
KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
|
|
This has nothing to do with a developer POV ./. user POV
The collision case exposes technical details about the failed process in the error message. If you don't care "failed" is all you need to read. If you do care "creating this file failed" helps you *NOTHING* Otoh "copying foo.tx to bar.txt doesn't work because: a) foo.txt doesn't exist b) you cannot access the path that contains foo.txt c) bar.txt already exists b) you cannot write into the path for bar.txt e) the server holding foo.txt does not respond f) there're probably more reasons." helps you *a lot* And again: the stuff (however minor and corner case it seems) HAS been reported to appropriate places and I frankly do not see what this has to do with the visual design group at all. PS: There's *one* actual bug been shown: Dolphin uses a custom action for a toolbutton and doesn't updated its enabled state at appropriate times. |
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan