[Aquamacs-devel] will aquamacs become a more native mac app with its UI?

[m t]

hi all,

i just discovered emacs/aquamacs and noticed aquamacs isn't afraid to veer away from the "classic" emacs approach, and is willing to have a native mac feel

still, it feels half-familiar/half-unfamiliar to me, so i was wondering what direction is aquamacs going in terms of their interface/ui?

an example of something that is a bit more "familiar"/"intuitive" to me is the latest experimental fork of notational velocity:

specifically this image, where you can imagine the note entry line having a similar function to emacs' mode line

http://media.tumblr.com/tumblr_la26mssy8f1qzh269.png

so will development of emacs stay truer to the original emacs?

or plan on introducing some features native only to mac? e.g. placing the mode line at the top of the screen and having it fade in/out only when being used (when C-x or M-x is pressed, etc.)

also, i'd like to lend a hand in terms of development as well, and wondering if there is a "new to aquamacs dev faq" available (i'm currently parsing the dev-list)

at first i didn't see any xcodeproj or interface builder files (i could have missed them or looked in the wrong branch), so was wondering whether or not there was an eventual migration to having a full-blown cocoa front-end?

(p.s. i eventually found the .xcodeproj file in the nextstep folder, had assumed that was the build output folder)

so if there is no interest to head towards emacs + core animation + other mac apps integration + fancy loud cgi explosions, then i'm fine with forking the project for my own personal (mis)use
it's simple to branch and see whether there is any appeal/interest in such a path

also wondering if any others have already tried this approach and found some of the obstacles to be too insurmountable and thus called it a day

that advice would be quite welcome and would save me much time from reinventing the M-x wheel

thnx,

mt

[m t]

it would have been nice for me to include the original link to nv:
http://elasticthreads.tumblr.com/post/1283428380/notational-velocity-forked-fullscreen-mode-menubar

thnx again, mt
_______________________________________________
Aquamacs-devel mailing list
Aquamac...@aquamacs.org
http://lists.aquamacs.org/mailman/listinfo.cgi/aquamacs-devel

[David Reitter]

M.,

On Oct 18, 2010, at 9:05 PM, m t wrote:
> still, it feels half-familiar/half-unfamiliar to me, so i was wondering what direction is aquamacs going in terms of their interface/ui?
> an example of something that is a bit more "familiar"/"intuitive" to me is the latest experimental fork of notational velocity:
>
> specifically this image, where you can imagine the note entry line having a similar function to emacs' mode line
> http://media.tumblr.com/tumblr_la26mssy8f1qzh269.png
> so will development of emacs stay truer to the original emacs?

Look, feel and functionality are different things.

The minibuffer and echo area can certainly be made to look more like Cocoa views, and they could be moved to the top of the frame (I'll accept a patch for this!).

As for functionality, it's unlikely that we'll get to use a Cocoa view to handle the actual interaction. Minibuffers have full Emacs editing capability. They have their own key maps; there is completion functionality and much more.

> or plan on introducing some features native only to mac? e.g. placing the mode line at the top of the screen and having it fade in/out only when being used (when C-x or M-x is pressed, etc.)

That would be good, and it could be done while integrating it with the rest of Emacs.

> also, i'd like to lend a hand in terms of development as well, and wondering if there is a "new to aquamacs dev faq" available
> (i'm currently parsing the dev-list)

It would be good to have such a document; however, there are plenty of documents for you to read. The Emacs Lisp Reference, for instance, which contains information about extending Emacs - not just on the Lisp level. There is nextstep/DEV-NOTES and nextstep/README.

That said, you will find hacking Emacs harder than your average model-view-controller Cocoa project.

> at first i didn't see any xcodeproj or interface builder files (i could have missed them or looked in the wrong branch), so was

As for XCode - I do not use it for Aquamacs development, and any project files will fail to build Aquamacs, unless they use the standard Makefiles. I'm not sure. They might build something closer to GNU Emacs, though.

> wondering whether or not there was an eventual migration to having a full-blown cocoa front-end?
> (p.s. i eventually found the .xcodeproj file in the nextstep folder, had assumed that was the build output folder)

What do you mean by "Cocoa front-end"?
I thought we're talking about a user interface, but now you're referring to the IDE.

I haven't had any plans to transition to XCode, but if someone sets it up, I'd be interested in trying it out.

> so if there is no interest to head towards emacs + core animation + other mac apps integration + fancy loud cgi explosions, then i'm fine with forking the project for my own personal (mis)use
> it's simple to branch and see whether there is any appeal/interest in such a path

There is plenty of interest to make Aquamacs more Mac-like. It has to integrate with Emacs Lisp, though, in order to be sustainable. That means that we can't use a lot of Cocoa views to handle UI tasks; where we can do so easily, we're doing it (e.g., the tool bar is a Cocoa one).

What I could see, however, is a Preferences system with good dialogs, good icons, good user interaction. This can be limited to a selection of the most important settings (similar to the Options menu). The customize interface remains for those who need to tweak some settings in more detail.

- D

--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and support the Aquamacs Project!

[m t]

On Oct 19, 2010, at 6:47 AM, David Reitter wrote:

The minibuffer and echo area can certainly be made to look more like Cocoa views, and they could be moved to the top of the frame (I'll accept a patch for this!).

As for functionality, it's unlikely that we'll get to use a Cocoa view to handle the actual interaction.  Minibuffers have full Emacs editing capability.  They have their own key maps; there is completion functionality and much more.  

ok, that's what i was wondering about mostly, whether the effort/undertaking would be somewhat straightforward or not

also, i'm coming at this from a "new to emacs" perspective, so i imagine it might be a case of "this is unfamiliar, let's change it to what i know" rather than learning to accept it for what it is and give it time

i'm trying to make sure i'm only taking the good and not the bad from the habits i'm used to

also, i'd like to lend a hand in terms of development as well, and wondering if there is a "new to aquamacs dev faq" available

(i'm currently parsing the dev-list)

It would be good to have such a document; however, there are plenty of documents for you to read.  The Emacs Lisp Reference, for instance, which contains information about extending Emacs - not just on the Lisp level.  There is nextstep/DEV-NOTES and nextstep/README.  

That said, you will find hacking Emacs harder than your average model-view-controller Cocoa project.

yes, that was my impression from first glance, hence my question pretty much the moment i took a gander at the source :)

i was initially wondering how much of a separation there was between the emacs "core" and the aquamacs "wrapper"

sounds like any modification to the emacs part would require a huge decoupling

my main thing here was that there was aquamacs info scattered everywhere, but none at github :)

there is some at emacswiki, some on this list, some in the source, some on the main site, etc.

it would be nice to have a central wiki

a simple thing i could do is during the learning phase, i could document whatever info i glean and then arrange to throw it onto the github wiki under a "beginning development for aquamacs"

basically lower the barrier to entry

wondering whether or not there was an eventual migration to having a full-blown cocoa front-end?

(p.s. i eventually found the .xcodeproj file in the nextstep folder, had assumed that was the build output folder)

What do you mean by "Cocoa front-end"?
I thought we're talking about a user interface, but now you're referring to the IDE.

yes, this was about the interface (front-end)

my p.s. was regarding an earlier statement that i wasn't able to find the .xcodeproj (which i ended up eventually doing)

the reason i didn't find the .xcodeproj was that the convention (from what i'm familiar with) is for the built app to be found within the "/nextstep/build" directory and not in the "/nextstep" directory, hence i just assumed that it was the build directory (without having even noticed the .xcodeproj file right beside it)

I haven't had any plans to transition to XCode, but if someone sets it up, I'd be interested in trying it out.

so if there is no interest to head towards emacs + core animation + other mac apps integration + fancy loud cgi explosions, then i'm fine with forking the project for my own personal (mis)use

it's simple to branch and see whether there is any appeal/interest in such a path

There is plenty of interest to make Aquamacs more Mac-like.  It has to integrate with Emacs Lisp, though, in order to be sustainable.  That means that we can't use a lot of Cocoa views to handle UI tasks;  where we can do so easily, we're doing it (e.g., the tool bar is a Cocoa one).

What I could see, however, is a Preferences system with good dialogs, good icons, good user interaction.  This can be limited to a selection of the most important settings (similar to the Options menu).  The customize interface remains for those who need to tweak some settings in more detail.

yes, the "preferences" section sort of jarred me from my "apple distortion field", transported me back to the "good old days" :)

i'm unsure what i think about that part of aquamacs, it looks like the way emacs handles preferences is a bit more powerful than what the usual mac application's preference pane provides

the emacs prefs are a combination preferences/help/man page

this is where i'm not even sure if "preferences" are even part of the original emacs, since it seems like all the options are something that are usually set within .emacs (correct me if i'm wrong here)

thnx for the info david,

milan

[David Reitter]

On Oct 19, 2010, at 10:57 AM, m t wrote:
>
> my main thing here was that there was aquamacs info scattered everywhere, but none at github :)

Correct. Wikis are easy to move around.

All things Emacs are centralized in the Emacs Wiki - this is where the Aquamacs Wiki resides.

> a simple thing i could do is during the learning phase, i could document whatever info i glean

Go right ahead.

The alternative would be .texi files extending the Emacs Lisp Reference manual, which is sort of a standard place for Emacs' developer-level documentation.

> the reason i didn't find the .xcodeproj was that the convention (from what i'm familiar with) is for the built app to be found within the "/nextstep/build" directory and not in the "/nextstep" directory, hence i just assumed that it was the build directory (without having even noticed the .xcodeproj file right beside it)

I've never used this project file, and I'm not sure if it can be used at all to build Aquamacs.