You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2008/01/08 14:14:28 UTC
Separating mac modeler code
Just realized that when running Modeler from Eclipse on Mac, I have a
bunch of functions absent from the menu, due to this code in
CayenneModelerFrame.java:
// Mac OS X doesn't use File->Exit, it uses CayenneModeler-
>Quit (command-Q)
if (!SystemUtils.IS_OS_MAC_OSX) {
fileMenu.addSeparator();
fileMenu.add(getAction(ExitAction.getActionName()).buildMenu());
}
// Mac OS X has it's own Preferences menu item under the
application menu
if (!SystemUtils.IS_OS_MAC_OSX) {
toolMenu.addSeparator();
toolMenu
.add(getAction(ConfigurePreferencesAction.getActionName()).buildMenu());
}
// Mac OS X "About CayenneModeler" appears under the
application menu, per Apple GUI standards
if (!SystemUtils.IS_OS_MAC_OSX)
helpMenu.add(getAction(AboutAction.getActionName()).buildMenu());
It would be nice if we could refactor this code to move all Mac
specific logic into the "modeler/cayenne-modeler-mac-ext" module...
(not only to make it runnable from Eclipse, but also to separate
platform-specific logic from the modeler core). Anybody wants to look
at this?
Thanks
Andrus
Re: Separating mac modeler code
Posted by Andrus Adamchik <an...@objectstyle.org>.
During release testing found one practical reason why we want to keep
OS X logic in an OS X module, and not in the main Modeler module.
Cross-platform Modeler misses Preferences and About menu. Not the end
of the world (as there is a Mac version available), but sort of an
example of what I meant.
Andrus
On Jan 8, 2008, at 4:51 PM, Michael Gentry wrote:
> I suppose I should've mentioned MacOSXMain. Sorry about that. I have
> a separate Eclipse cayenne-modeler-mac project just to run that part
> of the code. I don't think the changes hurt the Windows/Linux
> versions.
>
> I went for the quick, easy, practical fix, not necessarily the
> "correct" fix. It just seemed the easiest way to do it at the time.
> I didn't want those menu items to appear there on the Mac, so I made
> them conditional.
>
> Thanks,
>
> /dev/mrg
>
>
> On Jan 8, 2008 9:35 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>>
>> On Jan 8, 2008, at 4:27 PM, Michael Gentry wrote:
>>
>>> It is
>>> still usable and runnable inside Eclipse (preferences, about, and
>>> quit
>>> all work, they are just under the application menu).
>>
>>
>> My bad - I started the app from generic Main class. Now running from
>> MacOSXMain, I see those menu items.
>>
>>> I'm not sure moving
>>> the code out will be more beneficial -- you'd either have to
>>> entirely
>>> duplicate the menu creation code or go remove things afterwards that
>>> you don't want. This would add more clutter than just conditionally
>>> not adding the menu items in the first place.
>>
>> Splitting menu creation into a bunch of separate methods in a
>> superclass should allow to override some of them in the subclass.
>> This
>> still seems like the right thing to do, but considering the above, it
>> becomes very low priority on my list...
>>
>> Thanks,
>> Andrus
>>
>>
>>
>>
>
Re: Separating mac modeler code
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jan 8, 2008, at 4:51 PM, Michael Gentry wrote:
> I went for the quick, easy, practical fix, not necessarily the
> "correct" fix. It just seemed the easiest way to do it at the time.
> I didn't want those menu items to appear there on the Mac, so I made
> them conditional.
Actually I very much appreciate the new functionality, as it makes the
most sense on Mac. Just that sometimes my perfectionism kicks in at
the wrong time in the wrong place :-)
Andrus
Re: Separating mac modeler code
Posted by Michael Gentry <bl...@gmail.com>.
I suppose I should've mentioned MacOSXMain. Sorry about that. I have
a separate Eclipse cayenne-modeler-mac project just to run that part
of the code. I don't think the changes hurt the Windows/Linux
versions.
I went for the quick, easy, practical fix, not necessarily the
"correct" fix. It just seemed the easiest way to do it at the time.
I didn't want those menu items to appear there on the Mac, so I made
them conditional.
Thanks,
/dev/mrg
On Jan 8, 2008 9:35 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On Jan 8, 2008, at 4:27 PM, Michael Gentry wrote:
>
> > It is
> > still usable and runnable inside Eclipse (preferences, about, and quit
> > all work, they are just under the application menu).
>
>
> My bad - I started the app from generic Main class. Now running from
> MacOSXMain, I see those menu items.
>
> > I'm not sure moving
> > the code out will be more beneficial -- you'd either have to entirely
> > duplicate the menu creation code or go remove things afterwards that
> > you don't want. This would add more clutter than just conditionally
> > not adding the menu items in the first place.
>
> Splitting menu creation into a bunch of separate methods in a
> superclass should allow to override some of them in the subclass. This
> still seems like the right thing to do, but considering the above, it
> becomes very low priority on my list...
>
> Thanks,
> Andrus
>
>
>
>
Re: Separating mac modeler code
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jan 8, 2008, at 4:27 PM, Michael Gentry wrote:
> It is
> still usable and runnable inside Eclipse (preferences, about, and quit
> all work, they are just under the application menu).
My bad - I started the app from generic Main class. Now running from
MacOSXMain, I see those menu items.
> I'm not sure moving
> the code out will be more beneficial -- you'd either have to entirely
> duplicate the menu creation code or go remove things afterwards that
> you don't want. This would add more clutter than just conditionally
> not adding the menu items in the first place.
Splitting menu creation into a bunch of separate methods in a
superclass should allow to override some of them in the subclass. This
still seems like the right thing to do, but considering the above, it
becomes very low priority on my list...
Thanks,
Andrus
Re: Separating mac modeler code
Posted by Michael Gentry <bl...@gmail.com>.
I added this code to make the OS X version look more native. It is
still usable and runnable inside Eclipse (preferences, about, and quit
all work, they are just under the application menu). This seemed
reasonable for a development process setup to me. I'm not sure moving
the code out will be more beneficial -- you'd either have to entirely
duplicate the menu creation code or go remove things afterwards that
you don't want. This would add more clutter than just conditionally
not adding the menu items in the first place.
Unless I'm missing something ...
Thanks,
/dev/mrg
On Jan 8, 2008 8:14 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Just realized that when running Modeler from Eclipse on Mac, I have a
> bunch of functions absent from the menu, due to this code in
> CayenneModelerFrame.java:
>
> // Mac OS X doesn't use File->Exit, it uses CayenneModeler-
> >Quit (command-Q)
> if (!SystemUtils.IS_OS_MAC_OSX) {
> fileMenu.addSeparator();
>
> fileMenu.add(getAction(ExitAction.getActionName()).buildMenu());
> }
>
> // Mac OS X has it's own Preferences menu item under the
> application menu
> if (!SystemUtils.IS_OS_MAC_OSX) {
> toolMenu.addSeparator();
>
> toolMenu
> .add(getAction(ConfigurePreferencesAction.getActionName()).buildMenu());
> }
>
> // Mac OS X "About CayenneModeler" appears under the
> application menu, per Apple GUI standards
> if (!SystemUtils.IS_OS_MAC_OSX)
>
> helpMenu.add(getAction(AboutAction.getActionName()).buildMenu());
>
>
> It would be nice if we could refactor this code to move all Mac
> specific logic into the "modeler/cayenne-modeler-mac-ext" module...
> (not only to make it runnable from Eclipse, but also to separate
> platform-specific logic from the modeler core). Anybody wants to look
> at this?
>
> Thanks
> Andrus
>