Re: [sc-dev-old] EZPopUpMenu
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: EZPopUpMenu
by jostM-2
::
Rate this Message:
nescivi wrote: On Thursday 17 July 2008 04:21:01 jostM wrote:I've made a very convenient class named EZPopUpMenu, which I have been using for some time now. It simplifies a lot of the awkward coding needed for a regular SCPopUpMenu. I wanted to post it here before I make a quark out of it (or maybe it's even for the distro?) Any thoughts? http://www.glyph.de/projects/sc3/EZPopUpMenu.zipwhy post it on the old list? ;) simply by mistake. Thanks for pointing it out. I am mainly posting it to the dev-list, since I am using a class name which could some day conflict if there are other plans for EZPopUpMenu. However, if people think this is a sensible name for the functionality, then I will keep it. The help file explains everything clearly. jostM |
|
|
Re: EZPopUpMenu
by jostM-2
::
Rate this Message:
nescivi wrote: On Thursday 17 July 2008 04:21:01 jostM wrote:I've made a very convenient class named EZPopUpMenu, which I have been using for some time now. It simplifies a lot of the awkward coding needed for a regular SCPopUpMenu. I wanted to post it here before I make a quark out of it (or maybe it's even for the distro?) Any thoughts? http://www.glyph.de/projects/sc3/EZPopUpMenu.zipwhy post it on the old list? ;) sincerely, Marije OK, since there have been no further responses, I will make it a quark using the class name EZPopUpMenu. last chance to object ... jostM |
|
|
Re: EZPopUpMenu
by Scott Wilson-3
::
Rate this Message:
Jost,
I think this would be a candidate for including in Common, but two points: To make it consistent with the other EZ classes, it should have a label. If it's going to be in Common, it should not inherit from Crucial lib. (Or SCViewHolder should be in Common, although I don't think it's needed here.) S. On 18 Jul 2008, at 09:34, jostM wrote:
|
|
|
Re: EZPopUpMenu
by Scott Wilson-3
::
Rate this Message:
Alternatively, you could just add the convenience methods to the base classes.
S. On 18 Jul 2008, at 11:46, Scott Wilson wrote:
|
|
|
Re: EZPopUpMenu
by felix-38
::
Rate this Message:
I agree. 1. If you want to call it that, then it should be consistent and be included with the others. and its a welcome addition I'm sure. sorry to be slow on the response. 2. I have been thinking that SCViewHolder has proven a useful solution for quite a few people (and libraries) so it would be correct to move that out of crucial. 3. the EZ classes generally have more than one view whereas SCViewHolder has one view. but SCViewHolder subclasses usually put a FlowView as "the view" which means that you can set its background color or key down action or refresh and it makes all of the subviews look and feel like a single unit. On Fri, Jul 18, 2008 at 12:46 PM, Scott Wilson <s.d.wilson.1@...> wrote:
|
|
|
Re: EZPopUpMenu
by felix-38
::
Rate this Message:
how about: EZPopUpMenu( parent, bounds, label, items, selected ) where items can be an array [ "name" -> { }, "two" -> { } ] EZ to me means that you can build it one line of code, not have to go back and addItem and IMO the default should be empty, not filled with "Menu" and a function. currently you have it default to "Menu" -> { } but if one intends to only fill it with .addItem then you must first always remove the default item. TabbedView does this too: if you want to fill it manually you have to explicitly pass in blank labels array: [] to stop it from putting "tab1", "tab2", "tab3" so its not really a default, more of an example. and I end up having to go the class every time to look up how I need to call the constructors to avoid the defaults. f;lix On Fri, Jul 18, 2008 at 12:46 PM, Scott Wilson <s.d.wilson.1@...> wrote:
|
|
|
Re: EZPopUpMenu
by jostM-2
::
Rate this Message:
thanks both to scott and felix.
your comments make me realize that in some sense what I did is specialized, and perhaps I actually need to make two different ones. Here, first, were my motivations behind the class: 1. make syntax easy to code and read. 2. make easy adding and removing of items and their functions to a menu, and us syntax which is analogous to Lists. 3. make my class easily cross platform (hence the view holder). 4. (and this is what is specialized) make the menu default to returning to its first item automatically, like regular menus do. In that sense it is self-labeling, but also differs from some common popup menu functions. Point taken about starting with an empty menu, but actually this was also because I was treating the first item as a label. So there need to be two types: A) I think it may be correct that an EZPopUpMenu should indeed, for reasons of consistency, include a label, a composite view, and should be just like any other SCPopUpMenu for its function. It should also have add, instertAt, and remove methods. It could still also work like Felix suggest, using and associative array for the items and functions. B) The other one would work basically like the one I have now. Perhaps I could call it QuickPopUpMenu, QPopUpMenu, or something like that. That one I would just make a quark, because it is a useful specialized item. so I'll probably make the QPopUpMenu quark first, and I'll do the EZPopUpMenu some time in the coming few weeks. I also liked Scott's idea of simply adding convenience methods to the base class. But my structure is somewhat different: I have an array of functions and also a global function. Perhaps this would still be possible using the base class, without breaking code? jostM _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: EZPopUpMenu
by jostM-2
::
Rate this Message:
> > > TabbedView does this too: if you want to fill it manually you have to > explicitly pass in blank labels array: [] to stop it from putting > "tab1", "tab2", "tab3" > so its not really a default, more of an example. > and I end up having to go the class every time to look up how I need > to call the constructors to avoid the defaults. > > f;lix > As far as the TabbedView default is concerned, I'll have to look into that. I don't want to break code, but probably most people will use convenience methods like newBasic anyway, because they look better. In some sense this is a left over from the first versions, where I didn't have the add, and remove methods yet. I actually think these make much clearer coding than passing arrays in the constructor, however. best, jostM _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: EZPopUpMenu
by jostM-2
::
Rate this Message:
Scott Wilson wrote: > Alternatively, you could just add the convenience methods to the base > classes. > > S. > actually this would work. I would need to add and an instance variable, itemActions=[] , and then make the menu action default to : mymenu.action= {|obj| itemActions.at(obj.value).value(obj);}; that would allow for the automatic assignment of item actions, but would break no code, since earlier code would simply be overriding the default action, and would ignore the itemActions array. Then I could simply add my convenience methods, and the whole thing would work perfectly. what do you all think? I can write a +SCPopUpMenu for the time being. jostM _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: EZPopUpMenu
by jostM-2
::
Rate this Message:
jostM wrote: > > Scott Wilson wrote: >> Alternatively, you could just add the convenience methods to the base >> classes. >> >> S. >> > > actually this would work. > > I would need to add and an instance variable, itemActions=[] , and > then make the menu action default to : > > > mymenu.action= {|obj| itemActions.at(obj.value).value(obj);}; > > > that would allow for the automatic assignment of item actions, but > would break no code, since earlier code would simply be overriding the > default action, and would ignore the itemActions array. > > Then I could simply add my convenience methods, and the whole thing > would work perfectly. > > > what do you all think? > > I can write a +SCPopUpMenu for the time being. > > jostM > to make an EZPopUpMenu whcih includes all these possibilities, and is conform with the th other EZ classes. I think I'll simply go ahead with that. I think adding the above items to SCPopUpMenu would complicate a low level class, which should be kept simple. jostM _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
| Free Forum Powered by Nabble | Forum Help |