Hello fredvs, you wrote on Fri, 11 Sep 2020 15:40:46 -0700 (MST):
> >No, this is correct, but isn't this a bit overly complicated? > > No it was not really complicated and appears in the Object Inspector > panel. I didn't think of "complicated to implement" but of "complicated to process" - it requires _several_ additional steps between set-up and execution. You might justify it with the argument of "security", but you will have to bear the curse of extending the implementation often. But, so be it now. [Resizing] > Ha, ok, I should think to slower system. > On my i5 cpu, resizing is very fluent and "live". Hmm - slower system? I have an AMD A10-9700 @ 3.5GHz and 8GByte of memory. Maybe the integrated graphic unit, a Radeon R7, is a limiting factor, although it does even support some vectoring software. Another limiting factor could be the "amdgpu" driver the graphics system uses. BTW, for testing you might try the LXDE GUI which uses openbox as its window manager. > But ok, I will disable this and do the drawing only after resizing. I doubt this will help much. Perhaps I can try to find the cause of the ugly effect. This does NOT happen with any other window, so it must be specific to this very instance. Even your "main" program window resizes without any problem here, and this can be shrunk to nothing at all or blown up to take the whole screen. Perhaps you try to perform too many dynamic adjustments during resizing, or there might even be some repetitiv calls to adjustment functions? (BTW, when trying to trace the execution path of a program, I found numerous places where previously called handlers were called repetitively, only "safeguarded" by a flag or a previously set value. It was very difficult to follow, and in the ebd I did give up.) > About the width of the filename column, it is automatically resized to fit > the window, something like this: That's how I'd do it also, but that way, a splitter at its right side is useless. That splitter should belong to the column at its left (column 1), and consecutively so on. NO splitter at the rightmost column, as that always will straddle the pane boundary. (The splitters do have the problem that the column to modify depends on the direction of movement, if only one column is to be modified. There's no such problem if _both_ adjacent columns are modified as to keep both their respective _other_ border put.) > But yes, you are right, better not do it automatic and let the size > selected by the user. > I will do more test on resizing and fix it. The principal approach it correct, but the implementation might be somewhat improved... Just play a bit with it and you should see the unexpected behaviour. Or, as a simple way around the problem, set the sizes of colums "Ext", "Size" and "Date" to the (fixed) amount needed by their respective contents and let the user only adjust the window / pane width to fit his needs. Or DON'T size the columns automatically, but let the rightmost column(s) be covered by the window border if that's sized to small. (Which may even relief the visual resizing problem.) > >you to the top level directory "/". Which may be declared "works as > > intended", although, for the casual user, it might be somewhat > > surprising. It's also not really clear that the "empty row" can be > > extended and accepts > > OK, I will check this. > I did test it on Linux Debian 10, Linux wine, Windows 10, Raspbian RPI > and FreeBSD 12 and all seems good. No Windows here, no Debian, and no Raspberry version yet. And I suspect this to be more depending on the graphics system and driver (maybe you're using a manufacturer driver and a high[er] end card?) than on the respective distribution. Although the "amdgpu" driver is far more capable than the native "radeon", it might still be much more restricted than a manufacturer driver. I hope my complaints aren't too annoying. They're meant to provide the implementor with information of some user's experiences on some random system playing some with the advertised features of some still uncommon application. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
