3:24 p.m.
sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
>>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> However, one thing that you absolutely must not do is remove the Xt support.
Ben> This would be an incredibly unfriendly thing to do as it would prevent people
Ben> from using any widget set other than Qt or GTK. Keep in mind that people run
Ben> XEmacs on all sorts of different versions of X in Unix, and Xt is the standard
Ben> and the only toolkit that probably exists on all of these systems.
Yup. We also really need X/Xt resources to work. Jamie got that one right.
now I'm really not in the position to argue on technical stuff with
people like Ben or Bill or Michael, but shouldn't we at least consider
to remove some of the backward compatibility stuff for xemacs? gtk
can be compiled on quite a big range of unix machines (and on win32,
too by the way, although I don't think that this will be an option the
win32 people like to consider).
Now we have a growing set of features that can be used to a varying
extent on various platforms, and as far as I can tell, for all the nice
graphics stuff it's the win32 platform that works best. The only toolkit that is
a) free
b) stable enough
c) available on enough platforms
d) able to at least compete featurewise with the win32 toolkit
is gtk.
of course could everything be build from the intrinsics, but noone did
it by now and I don't think anybody will ever for the sole purpose of
giving XEmacs it's on gui.
just IMHO
jtl
3:53 p.m.
New subject: A gtk/kde-xemacs... a modest toolbar/menubar proposal...
On Tue, Mar 21, 2000 at 04:24:16PM +0100, Jens Lautenbacher wrote:
Now we have a growing set of features that can be used to a varying
extent on various platforms, and as far as I can tell, for all the nice
graphics stuff it's the win32 platform that works best. The only toolkit that is
a) free
b) stable enough
c) available on enough platforms
d) able to at least compete featurewise with the win32 toolkit
is gtk.
e) Able to open windows on different displays simultaneously
is not gtk (nor Qt for the matter).
OG.
4:45 p.m.
New subject: A gtk/kde-xemacs... a modest toolbar/menubar proposal...
Like Jens, I am not in any position to argue technical matters with
the XEmacs heavyweights... however I won't let this stop me from
registering my opinions.
GTK compiles on a wide variety of platforms and is growing more and
more widespread. It seems to me to be the GUI toolkit of the future,
as opposed to Xt which is "of the past", IMO. People writing new
applications tend not to mess around at the Xt level. Jens' arguments
make a lot of sense to me. Furthermore, since Gtk is fairly open, I
can imagine that if we need to make changes to Gtk we would be able to
do so and submit said changes back to the Gtk maintainers with a fair
likelihood of having them accepted (as opposed to, say, Motif or Xt).
In particular, I can imagine that patches to Gtk to allow for
simultaneous windows on different displays might be welcome. I
intend, when I get some time, to take a closer look at the Gtk sources
to see if this would in fact be a feasable modification.
Just my $0.002,
cgw
6:25 p.m.
New subject: A gtk/kde-xemacs... a modest toolbar/menubar proposal...
On Tue, Mar 21, 2000 at 10:45:27AM -0600, Charles G Waldman wrote:
In particular, I can imagine that patches to Gtk to allow for
simultaneous windows on different displays might be welcome. I
intend, when I get some time, to take a closer look at the Gtk sources
to see if this would in fact be a feasable modification.
Well, I did program in gtk and look at the sources. The main problem
is that the interface to all widget creations is intrinsially
monodisplay.
Quick code excerpt:
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
box1 = gtk_vbox_new(FALSE, 0);
video = videoout_new(quarter ? 360 : 720, quarter ? 240 : 480, grayscale ?
VO_TYPE_GRAYSCALE : VO_TYPE_PACKED_RGB);
fps = gtk_label_new("fps");
gtk_box_pack_start(GTK_BOX(box1), video, FALSE, FALSE, 0);
gtk_box_pack_start(GTK_BOX(box1), fps, TRUE, TRUE, 0);
gtk_container_add(GTK_CONTAINER(window), box1);
gtk_widget_show(video);
gtk_widget_show(fps);
gtk_widget_show(box1);
gtk_widget_show(window);
gtk_main();
Where to add the support for multiple display? Difficult question.
Maybe in gtk_window_new, resolving which display to use at show time?
What happens if you detach a widget and reattach it to another
container?
I.e., it sucks in this aspect (and numerous others, but heh...).
OG.
2:57 a.m.
New subject: A gtk/kde-xemacs... a modest toolbar/menubar proposal...
one standard trick here would be to introduce a new function gtk_set_display().
Olivier Galibert wrote:
On Tue, Mar 21, 2000 at 10:45:27AM -0600, Charles G Waldman wrote:
> In particular, I can imagine that patches to Gtk to allow for
> simultaneous windows on different displays might be welcome. I
> intend, when I get some time, to take a closer look at the Gtk sources
> to see if this would in fact be a feasable modification.
Well, I did program in gtk and look at the sources. The main problem
is that the interface to all widget creations is intrinsially
monodisplay.
Quick code excerpt:
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
box1 = gtk_vbox_new(FALSE, 0);
video = videoout_new(quarter ? 360 : 720, quarter ? 240 : 480, grayscale ?
VO_TYPE_GRAYSCALE : VO_TYPE_PACKED_RGB);
fps = gtk_label_new("fps");
gtk_box_pack_start(GTK_BOX(box1), video, FALSE, FALSE, 0);
gtk_box_pack_start(GTK_BOX(box1), fps, TRUE, TRUE, 0);
gtk_container_add(GTK_CONTAINER(window), box1);
gtk_widget_show(video);
gtk_widget_show(fps);
gtk_widget_show(box1);
gtk_widget_show(window);
gtk_main();
Where to add the support for multiple display? Difficult question.
Maybe in gtk_window_new, resolving which display to use at show time?
What happens if you detach a widget and reattach it to another
container?
I.e., it sucks in this aspect (and numerous others, but heh...).
OG.
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/typing.html.
8:47 a.m.
New subject: A gtk/kde-xemacs... a modest toolbar/menubar proposal...
At 01:25 PM 3/21/00 -0500, Olivier Galibert wrote:
Where to add the support for multiple display? Difficult question.
Maybe in gtk_window_new, resolving which display to use at show time?
What happens if you detach a widget and reattach it to another
container?
I.e., it sucks in this aspect (and numerous others, but heh...).
This is no different to mswindows. In my view you should view gtk as a
completely different window system that doesn't support multiple displays.
A port to gtk is XEmacs for the masses IMHO, I don't believe multiple
displays fits in that space.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
4:20 p.m.
New subject: A gtk/kde-xemacs... a modest toolbar/menubar proposal...
Jens Lautenbacher wrote on 21-March-2000:
->now I'm really not in the position to argue on technical stuff with
->people like Ben or Bill or Michael, but shouldn't we at least consider
->to remove some of the backward compatibility stuff for xemacs? gtk
->can be compiled on quite a big range of unix machines (and on win32,
->too by the way, although I don't think that this will be an option the
->win32 people like to consider).
Removing X/Xt support from XEmacs would result in all of us being sent
to bed with no supper.
Sure many Linux distros come with gtk/Qt, but Sun, IBM, etc. boxes[1]
do not, and aging boxes[2] may not have the disk/processing
power/graphics card to do so. Sysadmins have enough to do without
installing all of gnome (in extremis) just to be able to compile
XEmacs.
My opinion only,
nic[3]
Footnotes:
[1] Which aren't running Linux! (Or *BSD*, etc.)
[2] Used a _lot_ in academia.
[3] Who is lucky enough to have a decent Linux box, but used to have
horrendous problems when he didn't.
--
Dr N.J.Doye, Systems Programmer, NISS, PO Box 2674, Bath. BA2 7XY
6:50 p.m.
New subject: A gtk/kde-xemacs... a modest toolbar/menubar proposal...
On Tue, 21 Mar 2000 16:24:16 +0100, Jens Lautenbacher <jtl(a)schlund.de> said:
b) stable enough
c) available on enough platforms
d) able to at least compete featurewise with the win32 toolkit
is gtk.
At least on AIX, you get to *first* install one or more of the GNU
tools (autoconf, automake, GNU make, libtool). *Then* you can
look at building glib and then gtk+.
THat's a DAMNED lot of extra stuff you need over and above what IBM
ships. XEmacs currently builds Just Fine on an AIX box that has nothing
but the standard IBM-supplied operating system and C compiler. At the
current time, everything else is *OPTIONAL*.
Please don't make it mandatory to install additional stuff just to
get the editor to display a window. ;)
/Valdis (who has Gtk+ and Enlightenment on AIX, but is quite the rarity)
8:54 a.m.
New subject: A gtk/kde-xemacs... a modest toolbar/menubar proposal...
At 04:24 PM 3/21/00 +0100, Jens Lautenbacher wrote:
now I'm really not in the position to argue on technical stuff
with
people like Ben or Bill or Michael, but shouldn't we at least consider
to remove some of the backward compatibility stuff for xemacs? gtk
This would be stupidity IMHO by hacking off a large number of users. But
its also unneccessary - just treat gtk as a different platform and then
build either for Xt or gtk but not both. In fact I would advocate treating
gtk as a completely different device/console etc because then you *could*
build with support for both (as you can under cygwin with mswindows)
without the two interfering with each other. Trying to integrate the two
seems doomed to failure IMHO.
Now we have a growing set of features that can be used to a varying
extent on various platforms, and as far as I can tell, for all the nice
graphics stuff it's the win32 platform that works best. The only toolkit
that is
a) free
b) stable enough
c) available on enough platforms
d) able to at least compete featurewise with the win32 toolkit
is gtk.
Well right, I think these are the good reasons for doing a gtk port, but
when we did the mswindows port we didn't stop supporting X ....
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
9012
days inactive
9013
days old
8 comments
7 participants
participants (7)
-
Andy Piper -
Ben Wing -
Charles G Waldman -
Jens Lautenbacher -
N J Doye -
Olivier Galibert -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks