On Fri, Jun 1, 2018 at 5:11 PM, Peter Uhnák <i.uh...@gmail.com> wrote:
> Hi,
>
> @Cyril
>
> I don't know if it should be in the SettingBrowser since Pharo currently
>> comes with only one menu (if someone know how to implement a new one it
>> will be easy for him to find the option to change the pragma of the
>> MenuBarMorph), but the pragma should be parametrizable in any case.
>
>
> Adding a new pragma is not a problem, you can use whatever name you want
> (see e.g. worldMenuExample pragma), but there is no way to tell Pharo to
> use this instead of the default one.
>
>
> I don't know if it should be in the SettingBrowser since Pharo currently comes
>> with only one menu
>
>
> Oh, never mind. I just found out that this is already in place, in
> WorldState class>>desktopMenuPragmaKeyword:. I don't know how I managed
> to miss this in the past.
> So if the new menu bar just uses this (WorldState
> class>>discoveredMenuPragmaKeyword),
> or uses a similar mechanism (so the menus can differ, which would be also
> nice), then all is well.
>
Well, actually we are right now doing this:
open
"self open"
self new
menuBarItems: WorldState new menuBuilder menuSpec items;
open.
So the menu bar uses the menuBuilder used by the system, which is hiding
the pragma and everything from us :)
>
> I'll rephrase, we have ideas to manage all those problems but how do we
>> implement it? Currently there is no widget to do that and sadly we don't
>> have enough time to create them :(
>
>
> I don't know about menu morph, but the bottom menu can handle overflow,
> can that be used for the time-being?
>
Well, one thing is to overflow like the bottom bar (growing so all items
fit). But I'd like to have a solution (now for this iteration) where
overflowing items are hidden and shown in a "..." button or a hamburguer
button.
>
> @Sean:
>
> Were these projects where you were the only user?
>
>
> No.
>
> For experienced users, I struggle to see how "Navigate over to Xyz which
>> takes up screen real estate" is better than "click wherever the cursor
>> happens
>> to be"
>
>
> Pharo adds 25px margin on all sides of a full-screen window. This is
> enough to add menu to each side. So in fact Pharo already wastes 4x as much
> space to do what you want.
> Secondly, my menu doesn't match the world menu, it provides the most
> important/common options that user needs; so yes, it is faster, because it
> is one or two clicks instead of going through items that are not relevant
> to the user.
> Finally, even if I didn't consider full screen, very often I find myself
> having to move windows, just so I can expose a piece of desktop to click on.
>
> Please don't forget that some Pharo applications are meant for
> (non-programmer) end users, and not for (Pharo) developers.
>
> But don't see a problem with adding a checkbox to settings "Menu bar [x]".
> There is already such a setting for the bottom task bar ("Taskbar...").
>
> Peter
>
> On Fri, Jun 1, 2018 at 4:27 PM, Alistair Grant <akgrant0...@gmail.com>
> wrote:
>
>> Hi Cyril,
>>
>> On Fri, Jun 01, 2018 at 03:48:54PM +0200, Cyril Ferlicot D. wrote:
>> > On 01/06/2018 15:18, Alistair Grant wrote:
>> >
>> > Personally, I would like to have display strategies for the WorldMenu
>> > and the user could select the one he likes (because nobody will agree on
>> > UI).
>> > For example:
>> > - Menu bar strategy
>> > - World menu strategy
>> > - Start button strategy
>> > - Composite strategy to have multiple ones
>> >
>> > Now it is simple to do the two first, but I will probably not have the
>> > time to implement the "Start button" one.
>>
>> Fair enough. (I haven't had time to do much of anything recently)
>>
>>
>>
>> On Fri, Jun 01, 2018 at 03:56:14PM +0200, Cyril Ferlicot D. wrote:
>> > On 01/06/2018 15:25, Peter Uhn??k wrote:
>> > >
>> > > Also, is it (easily) possible to configure the position of the menu?
>> > > Both top/down, as well as RTL and LTR direction (or right-aligned LTR)
>> > > which I mentioned for the bottom menu in an earlier github discussion.
>> > >
>> >
>> > For now I don't think so. I think it would be cool to integrate this
>> > first version then everyone can try to improve it.
>>
>> +1 (to integrating a first version and iterating)
>>
>> Cheers,
>> Alistair
>>
>>
>>
>
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr
<http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
