Hello fredvs,
sorry for the delay, I came only now around to inspect your last additions.
you wrote on Sun, 6 Sep 2020 14:09:17 -0700 (MST):
> > But you didn't do this for the _form_, but set the _contoller_'s
> > respectivevariables.
^ space missing!
> It does it for the form too via the _contoller_'s respectivevariables who
> set then to the form, for example font size+name.
> (or maybe i miss something).
No, this is correct, but isn't this a bit overly complicated?
This approach requires to define an additional variable _and_ an
appropriate handler function for _every_ property of the window that
ought to be settable, and prohibits modification of anything else.
Although one might be interested in the latter possibility from an
implementor's point of view, seen from a programmer using the component
in need or just wishing to access a property not exposed through the
controller it's a hassle.
> Note that the size and position of the form is given by the stat file that
> you may edit and set as you want.
That's fine. In principle.
At least with my setup (openbox 3.6.1 on Slackware 64, kernel 5.4.61,
fpc 3.0.4 [2020/03/06] for x86_64, Xorg server 1.20.9, anything else?)
it doesn't quite like to be resized. It seems there's a minimum size (the
design size?) below that it will not go, but on enlarging the window, it
doesn't even show the right lateral sizing handle, and it acts quite
erratically when moving the handle, often jumping to some prior size or
even halt with the handle way outside the window frame when one stops
moving it. It may be that this is an openbox quirk, as I think to remember
that Martin mentioned several times that different window managers would
act rather differently, and even implemented aa number of work-arounds for
some of these quirks.
> But if you want some _contoller_ parameters who will control the _form_, I
> will add it.
Oh, there might be quite some one could want at times...
But, just found while playing around with it some: The splitters in the
main listing windows act weird. Trying to _reduce_ the width of a column
(especially the file column) didn't work, trying to extend the file column
beyond the "Ext" column made the whole listing disappear. Extending the
"Ext" column _reduces_ the file column width by the same amount, but on
the _other_ side. Same effect with the "Size" column, and trying to extend
this beyond the pane limit also removes the whole listing. If the latter
happens, the listing doesn't seem to reappear by any sizing action, you
must close the dialog and reopen it - for me, it always reappeared then at
least (but maybe only because the column setting doesn't get saved right
now, which might be a candidate for "stat"ting also, though not right now
yet!).
BTW, funnily the "Date" column _can_ be sized by moving its _right_ border
(splitter), "sometimes" even beyond the right pane border, but it does move
its _left_ border, as do "all" the other columns...
> I am very happy that you like it and thank you very much for you always
> clever advises an ideas.
Well, most of these are triggered by problems found on playing with the
possibilities, and often by my queer imaginations about possible
applications.
These things are already so complex that it's already impossible to keep
them free of unexpected behaviour and unwanted interactions, and it's just
as impossible to test all possible functions or even expected uses.
So, there's no shortage of interesting effects and always a good supply of
required maintenance activity...
May I still respond with "Have a lot of fun"?
BTW:
you wrote on Sun, 6 Sep 2020 19:25:52 -0700 (MST):
> In last commit, added "Custom Places" panel.
> You may add your favorite directories clicking 2x on the empty row.
That's a good idea. That's, it was, if it worked as expected (for me...).
For one, if there's "empty space" in the list pane, clicking there brings
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
several entries, because it looks like a single line field firstly.
It might be more apparent that it's a list field if it was directly
adjacent to the list of "fixed" entries, where it could show multiple
lines from the beginning.
Or it might even be made into an integral part of that list?
Sorry, even another problem / weird idea yet...
you wrote on Tue, 8 Sep 2020 08:11:13 -0700 (MST):
> I did add the component FileDialogX in mseide-msegui code.
> With last commit of mseide-msegui, compile mseide and you will get a new
> tab + new FileDialogX component in the component palette.
Thanks for that,
I will "ASAP" download this version and put it to use!
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-
