Bug 1149156 - partitioner: can't adjust display size - leaving screen size on the table
partitioner: can't adjust display size - leaving screen size on the table
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: YaST2
Leap 15.1
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/rDOjmS4p
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-03 08:39 UTC by Kai Dupke
Modified: 2019-09-09 10:49 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
eample of not using screen size optimal (127.30 KB, image/png)
2019-09-03 08:39 UTC, Kai Dupke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Dupke 2019-09-03 08:39:20 UTC
Created attachment 816617 [details]
eample of not using screen size optimal

The partitioner shows the system view on the left and other stuff on the right.

I am not able to adjust the size of the system view, a handle on the bar between the left and right part is missing
Comment 1 Ancor Gonzalez Sosa 2019-09-06 08:40:17 UTC
Our current widgets library does not allow such thing. The split between the "System View" tree and the area with the tables/forms is done via a so-called HBox (horizontal box) widget. There is no way to make the dimensions of those boxes draggable for the users.

HuHa, is there any way to achieve something similar to what Kai suggests?
Comment 2 Ancor Gonzalez Sosa 2019-09-06 08:41:47 UTC
Anyway, since we are currently rethinking some aspects of our widgets library (libYUI), I created a Trello card to prioritize this alongside other libYUI tasks.
Comment 3 Stefan Hundhammer 2019-09-09 10:06:49 UTC
(In reply to Ancor Gonzalez Sosa from comment #1)
> HuHa, is there any way to achieve something similar to what Kai suggests?

No. That would mean a much deeper integration of the application logic and the Qt UI. We'd need a dedicated widget for this. I am advocating this anyway, but for entirely different reasons.


And even if we had this, just look at the screenshot: If you'd move the boundary between the tree and the content subwindow on the right, the horizontal scroll bar would no longer be 172 pixels wide of the 1050 pixels available (i.e. ~16%), but maybe 200 (i.e. ~20%).

This would be a huge amount of work for cosmetic changes, leaving the true problem untouched: There are way too many Btrfs subvolumes. They clutter not only this view, but /etc/fstab, the output of the "df" command, the output of the "mount" command and basically everything that deals with mounts. 

Everything else in the device graph is plain and simple, but those Btrfs subvolumes clutter everything.

If you want UI cosmetics, I suggest a button "Open in new window" that would open a fullscreen dialog just with that device graph and only a "Close" button.
Comment 4 Kai Dupke 2019-09-09 10:15:38 UTC
The one has nothing to do with the other.

a) wide screen displays are becoming more and more used - it looks not good to waist so much screen size on the left 'menue'

This bug is about this.

b) btrfs subvolumes creates more content, which fills in the available room

This makes sense for me but looks more like a enhancement request.

I recommend not to open any new window but collaps the tree within the available window. Running the tool over a not so fast line will make it close to not tolerable with any new window clreation.
Comment 5 Stefan Hundhammer 2019-09-09 10:24:43 UTC
(In reply to Kai Dupke from comment #4)
> a) wide screen displays are becoming more and more used - it looks not good
> to waist so much screen size on the left 'menue'
> 
> This bug is about this.

It would look a lot worse, in particular in ANY of the other views, to make the tree on the left much narrower and to have much more empty space in the tables that normally appear on the right side. 

IIRC we had that, and people demanded we should change it.

This device graph view is a very special case. It doesn't really fit here; it is very much a media break.
Comment 6 Stefan Hundhammer 2019-09-09 10:30:35 UTC
(In reply to Kai Dupke from comment #4)
> I recommend not to open any new window but collaps the tree within the
> available window. Running the tool over a not so fast line will make it
> close to not tolerable with any new window clreation.

News flash: Qt does not use Xlib primitives anymore since Qt 5.0. They are rendering into a pixel buffer and transfer the entire pixel buffer to the display (the X or Wayland server) each time. That was a conscious design decision by the upstream Qt project years ago; they felt that very few users need X11 over a slow network these days.

It makes zero difference if you open a new window or not; X over ssh is painfully slow in every case. It is so slow, as a matter of fact, that I even added a dedicated command line option "--slow-update" to my QDirStat for that specific reason.

Where does that leave us with YaST? We can only recommend users to use the NCurses UI if they need to use YaST over ssh on a slow network connection.
Comment 7 Kai Dupke 2019-09-09 10:37:25 UTC
(In reply to Stefan Hundhammer from comment #6)

> News flash: Qt does not use Xlib primitives anymore since Qt 5.0. 

News Flash: Users might not know what happens in the background and shoot the messenger. 

If an update inside a window is slow, then it is a problem of the system (as being slow). If an update seems to be slow because a new window is opened then it is seen as a problem of the screen design. As users do not test this side by side, they only know one look.

NB: I was up to file a bug about new window coming up instead of content of a window is changing. Looks like this does not make any sense because of the QT change. Hoever, it still feels like the new Window is causing the loss of the efficiency, not QT is doing so....
Comment 8 Stefan Hundhammer 2019-09-09 10:49:00 UTC
(In reply to Kai Dupke from comment #7)
> (In reply to Stefan Hundhammer from comment #6)
> 
> > News flash: Qt does not use Xlib primitives anymore since Qt 5.0. 
> 
> News Flash: Users might not know what happens in the background and shoot
> the messenger. 

You mean those 0.1% of our users who use remote X over a slow connection?