On Sep 27, 2020 3:23 PM, Gregg Young <lswitcher-dev@2rosenthals.com> wrote:
Hi Lewis
>
>Hi, and sorry for lagging so far behind...
You have a lot on your plate so don't worry about this.
>
>On 09/27/20 07:44 am, Alfredo Fernández Díaz wrote:
>>On 20/09/27 04:15, Gregg Young wrote:
>>>On Sun, 27 Sep 2020 01:04:42 +0200 Alfredo Fernández Díaz wrote:
>>>>
>>>>On 20/09/26 23:01, Gregg Young wrote:
>>>>Of course, I see. But if the code in XCenter did the same, I mean, if
>>>>"reduce Desktop" is checked, check if something is using it already
>>>>on
>>>>startup, and act accordingly, wouldn't it all appear to work OK? At
>>>>least no application would cause the other to fail, and it's not like
>>>>there are many more to interfere out there. Am I missing something
>>>>else?
>>>
>>>You have a plan for forcing the update of XWP on all systems and
>>>preventing
>>>the use of Warp Center which we can't fix and you know for certain
>>>these
>>>are the only programs that use this?
>>
>>I always have a plan. Phase I is getting to know how all of this works
>>without looking at the code. Thanks for your help ;)
>>
>>I imagine the lack of a WarpCenter object in ArcaOS kind of prevents
>>its use. If the people at ArcaNoae were really determined to do that
>>I imagine they could also prevent the SmartCenter class from being
>>registered in the first place in future versions. That would be an even
>>safer way to be sure nothing will interfere with what's not even there.
>>And I imagine those people would want as many customers as possible to
>>be reasonably updated. Seriously, how many people are left outside that
>>lot (besides me ;)?
>>
>
>If you install ArcaOS and deselect ArcaOS Desktop, you get WarpCenter.
>There was never any intention of removing it from the distro.
>
>In larger environments, change implies a learning curve. We wanted
>ArcaOS to be able to seamlessly replace existing Warp 4 installations
>without requiring users (generally less technically savvy than we,
>particularly pertaining to matters OS/2) to learn new steps to
>accomplish the same tasks. You can even use the old Warp 3 toolbar (and
>we have some enterprise clients who do).
I kinda thought that this was how AcraOS handle things like this.
>
>>Then it's all a matter of documenting things properly (do not do this
>>and that for such and such reason: just a twist on the current docs)
>>and wait for reports of the three people in the entire universe who
>>still see something break up in their systems.
>>
>
>:-)
>
>>But you know, I've been planning to upgrade my lSwitcher for some time
>>now, so don't get upset. I would say you still have years to see my
>>plans change. :-)
>>
>
>:-D
>
>>...
>>>>Almost there, see attachment. Could you move it further left to align
>>>>with 'Idioma' above, maybe? I think we'd be done for good.
>>>
>>>On my system if I do that I see a strange clipped box following the +
>>>sign.
>>>I can move 'Idioma' to the right if you like. Thanks
>>
>>I'll have a look at that later. I've changed a couple of strings
>>to stay closer to the current English menu (lSwitcher settings ->
>>Properties, and help mnemonics).
>>
>>[...]
>>>>-Open a WPS folder window. Bring up the PM popup, 'C' is for close,
>>>>and works; good. Open the folder again, bring up the popup menu for
>>>>the folder on the taskbar ('Move' is in there, btw): now 'Close' is a
>>>>submenu with 'Close' and 'Quit', and 'Quit' does nothing, as I half
>>>>expected. I suppose that's meant for applications (which have
>>>>'Close',
>>>>'Quit', 'SigKill', 'DosKill'...)
>>>
>>>I am not clear as to what you are telling me here.
>>
>>Yeah, I've written better pieces. Have a look at the screenshot.
>>'Programs' is a WPS folder: you can make it 'Close' but not 'Quit'.
>>Maybe the 'Close' menu should be replaced by its first child item,
>>which is the only one that works in that situation.
>>
>
>I had to walk through your steps, but indeed, this also occurs with the
>widget.
Not surprising since they both use the same code for this.
>
>Close is not a valid action for a folder object, and should be filtered
>from the list of actions.
Close is valid and works. Quit on the other hand not so much. If close isn't valid why is it on the folder's own menu?
Doing so, then narrows the Close > submenu to
>just Close, it's "first child item" (Close > Close), making the submenu
>superfluous.
Yes I think I will eliminate the submenu completely and just put the kill choices under close on the main menu when appropriate. Quit goes away.
>
>It's often hard to describe some of these oddities. I think you did an
>excellent job, my friend, but a visual aid (such as provided here) would
>probably have come in handy to make the initial point. :-)
>
>So, we have a few issues:
>
>1. Quit is not a valid action for folder objects and should be removed
>from the Close submenu;
>2. An only child on a submenu is very lonely :-( ;
See plan above for 1 & 2.
>3. Missing Move action for icons in the popup and their context menus
>there;
I need to figure out why move was filtered on the popup. Don't think I did that. Alfred is move on the popup menus in your prehistoric version? It behaves much differently than the other commands in that it acts across virtual desktops which may mess with the popup somehow.
>4. Close from the popup hotkey only performs...what? Default Close, as
>from the left window manager menu?
The hotkeys work on the selected process. It sends a WM_CLOSE message to that process.
>5. Q from the context menu in the popup closes the context menu (not
>a bad feature; surely harmless, but I'm not sure we documented that
>anywhere);
>6. Q from the popup (no context menu open) is documented as quitting,
These (5 & 6) will go away.
> but this does not seem to work, and Q has been removed from the list
> of popup hotkeys in the UI;
>7. Ultimately, we are going to have to do something with the hotkey
> selections (I just re-read the documentation) - my RFE for these
> would be to make them customizable, defaulting to English, and use
> the customized key names in the popup.
The only way this can happen is if I make the popup permanently sticky. The mnemonics don't work with the ALT or CTL key down. It is the hotkeys that make them appear to work.
>
>
>Of the above, 1, 2, 3, and 6 seem like blockers to the 2.92 release.
>Documentation pertaining to 5 needs a tweak.
1, 2, 5, 6 go away with my purposed change. I will need to determine if there is a technical reason for filtering move from the popup.
>
>>>>
>>>>-Packaging: any particular reason why we keep old English readmes,
>>>>i.e.
>>>>readme.v*?
>>>
>>>I always package the historic readmes on my first release. They can
>>>probably go away now. Thanks
>>
>>Thank you for all you do ^^
>>
>
>Ditto, that.
Thanks
Gregg
P.S. My new keyboard and mouse (Logitech MK550) just arrived. Not sure I like the keyboard but it is nice to have a fully working mouse button 2.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message is sent to you because you are subscribed to
the mailing list <lswitcher-dev@2rosenthals.com>.
To unsubscribe, E-mail to: <lswitcher-dev-off@2rosenthals.com>
To switch to the DIGEST mode, E-mail to <lswitcher-dev-digest@2rosenthals.com>
To switch to the INDEX mode, E-mail to <lswitcher-dev-index@2rosenthals.com>
Send administrative queries to <lswitcher-dev-request@2rosenthals.com>
To subscribe (new addresses), E-mail to: <lswitcher-dev-on@2rosenthals.com> and reply to the confirmation email.
Web archives are publicly available at: http://lists.2rosenthals.com
This list is hosted by Rosenthal & Rosenthal, LLC
P.O. Box 281, Deer Park, NY 11729-0281. Non-
electronic communications related to content
contained in these messages should be directed
to the above address. (CAN-SPAM Act of 2003)
back to list