Let the user drag and adjust the size of FL window (and also the preview panel partition)

[raindropsfromsky]

Problem statement:

The preview panel is very tiny, and we get to see only a small thumbnail. The user is not allowed to change its size.

Secondly, FL has a setting to change the size of the window by using s slider, which is inconvenient to use, and the user does not get a direct feedback about the size he is setting.

Proposed solution:

1. Let the user drag the borders of the FL window to change its size.
2. Let the user drag the partition between the results pane and the preview pane.
   The preview should get resized automatically to take up the space at right.

[jjw24]

You can now expand the width of the search window via shortcut Ctrl + Plus/Minus.

[jjw24]

Let the user drag the partition between the results pane and the preview pane.
The preview should get resized automatically to take up the space at right.

@Flow-Launcher/team this something we want to implement as well?

[z1nc0r3]

You can now expand the width of the search window via the shortcut Ctrl + Plus/Minus.

@jjw24 I think this should be Ctrl + [ and Ctrl + ]

[onesounds]

Let the user drag the partition between the results pane and the preview pane.
The preview should get resized automatically to take up the space at right.

@Flow-Launcher/team this something we want to implement as well?

The UI of this proposal is correct and should be like this. It's just that it's structurally difficult to make it like this. (Using slider was plan B.) There are many issues to discuss and It's a costly task. I have some plans for this but it's hard to promise to work on it.

[raindropsfromsky]

(Using slider was plan B.)

But when we use the slider, the preview panel does not show its effect accurately: The preview does not show the width of the bar as a percentage of the width of the monitor. The actual bar looks totally different.

[jjw24]

But when we use the slider, the preview panel does not show its effect accurately: The preview does not show the width of the bar as a percentage of the width of the monitor. The actual bar looks totally different.

I think the preview in Theme would be too small to accurately determine if the search window is the right width? I often just trigger flow to get an exact feel.

[onesounds]

(Using slider was plan B.)

But when we use the slider, the preview panel does not show its effect accurately: The preview does not show the width of the bar as a percentage of the width of the monitor. The actual bar looks totally different.

When I worked on the slider, it was impossible to adjust the size of the flow. It was only possible to change it to a theme. The theme preview was also not a problem because the size was fixed.

Now I've improved the functionality to resize the flow, but the theme preview is not appropriate for you to see. Likewise, functionality is not at its best (again, this was second best). I know the way you're talking is right. I'm saying it's hard to make. It is also of low importance.

To implement the function you mentioned, refactoring of the shadow function is necessary. Or the shadow function should be eliminated. (as you know, this is not a normal window. This is the limitation of the framework we use.)

I did this knowing that there was a problem with the inaccuracy of the preview or the UI of the slider. This was because the function of adjusting the size was the top priority. To avoid raising this issue, we don't produce resizing, or we can solve everything and then release it. However, it was judged that it was more problematic not to include a size control function due to such an issue. How about you? Should I not release it if it's not perfect? Imagine this. We've released a feature that allows you to change the size of the flow. You don't say, "Wow, it's finally being resized?" but You say, "Why do you make this into a slider?" It's okay to talk like this. But I hope you understand when we explain the situation.

basically we don't even get paid, We are short of ability. and there's a limit to our work resources. In my case, I don't want to work on this task because there is a priority to choose from. Once again, I said your idea was right. But by my standards it's like repairing car scratches. I think engine repair is a priority.

If this is a really important problem, we can eliminate the shadow function and implement this function. Currently, draft PR exists and works well. (Of course, shadow function is very important.)

[deefrawley]

I agree this should be put on the backburner, perhaps for a future release that focuses on the UI.

[github-actions]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 5 days.