emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Motif support


From: Óscar Fuentes
Subject: Re: Motif support
Date: Wed, 22 Dec 2021 21:08:31 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> What I try to say is that it is possible to do gui on it's own.
>
> It's possible, sure.  But why would we want to do that?

It gives you ultimate control over the GUI. Start with a surface and put
there whatever you want.

> We have enough work on our hands without that.

He is not asking you to do the work ;-)

>> Menus, toolbar and scrollbar are not very hard to do without external
>> toolkit, and since this thread took up that Emacs talks to numerous 
>> toolkits, it
>> may be pointed out that doing own thing might be a simplification of the code
>> base.
>
> If you read this thread since its beginning, you have read the message
> where I explained that it won't simplify the code, because eventually
> you'd need to call the GUI APIs that are different for different
> platforms.

You can use a cross-platform layer for that. There are many readily
available, developed by the game crowd. Some of them are ridiculously
simple and powerful at the same time.

>> > Did you look at, for example, the MS-Windows back-end of the Cairo
>> > port to Windows?
>> 
>> Not really. I am quite sure they need to talk to the OS at some point, but
>> that is different to rely on OS to render menus and buttons, or just low 
>> level
>> stuff to open a window or blit ssurfaces.
>
> I suggest that you look at the code, because the reality is quite
> different from what you think.  The calls to Win32 APIs are all over
> the place there.

See above.

>> I am not trying to be devil't advocate, or annoying, I just believe that code
>> base would be easier to work and experiment with without so many different 
>> paths.
>
> If you can suggest reasonable practical ways of doing that, by all
> means go ahead.  I didn't yet hear any such proposal in this
> discussion.

It would be not easy. Well, actually, the easier part would be the pure
graphical one. But integrating events and, above all, defining, exposing
and implementing on the display engine the new primitives for the
drawing features we wish to expose to Elisp looks like the most
difficult part to me.

And then every possible technique for the graphical part has its own
rough edges that you need to overcome. But if done right Emacs would
give any other modern editor a run for his money.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]