12:26 p.m.
SL Baur <steve(a)vmailer.xemacs.org> writes:
Olivier Galibert <galibert(a)pobox.com> writes:
> On Mon, Jun 08, 1998 at 10:47:16PM -0700, Ben Wing wrote:
> [Nobody's familiar with the lwlib code anymore]
> Do you think we should aim at removing it
Yes.
> (using motif/lesstif, gtk, Qt, whatever (all of them ?)) ?
Motif/lesstif no. Gtk or Qt (or both if the Qt licensing weren't so
fucked) are preferable.
Well, we talked about this before... The big problem is that neither
gtk or Qt use Xt, and therfore all the resource-related code and event
loops would need to be rewritten. I for one would be more interested
in spending the time to really understand/rewrite/cleanup lwlib than
deal with the other headaches. I *like* the look and feel of lwlib
(if a couple of minor nits could be worked out of them). After my
current round of windmill tilting is done, I'll have a look at them.
I'd like to keep them, so I guess I'll do the maintaining.
--
Jareth Hein | jareth(a)camelot-soft.com | ハイン ジェラス
Toolsmith & Program lead | http://www.camelot-soft.com | 開発部チーフ
Camelot Software, Ltd. | |（株）キャメロット
"Contrary to popular belief, penguins are not the salvation of modern
technology. Neither do they throw parties for the urban proletariat."
12:57 p.m.
New subject: Bug (I think) limit on popup menu strings
At 08:26 PM 6/9/98 +0900, P. E. Jareth Hein wrote:
SL Baur <steve(a)vmailer.xemacs.org> writes:
> Olivier Galibert <galibert(a)pobox.com> writes:
>
> > On Mon, Jun 08, 1998 at 10:47:16PM -0700, Ben Wing wrote:
> > [Nobody's familiar with the lwlib code anymore]
>
> > Do you think we should aim at removing it
>
> Yes.
>
> > (using motif/lesstif, gtk, Qt, whatever (all of them ?)) ?
>
> Motif/lesstif no. Gtk or Qt (or both if the Qt licensing weren't so
> fucked) are preferable.
Well, we talked about this before... The big problem is that neither
gtk or Qt use Xt, and therfore all the resource-related code and event
loops would need to be rewritten. I for one would be more interested
in spending the time to really understand/rewrite/cleanup lwlib than
deal with the other headaches. I *like* the look and feel of lwlib
(if a couple of minor nits could be worked out of them). After my
current round of windmill tilting is done, I'll have a look at them.
I'd like to keep them, so I guess I'll do the maintaining.
I like lwlib as well - although I don't get to see the results much
anymore....
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
1:52 p.m.
New subject: Bug (I think) limit on popup menu strings
On Tue, Jun 09, 1998 at 08:26:21PM +0900, P. E. Jareth Hein wrote:
Well, we talked about this before... The big problem is that
neither
gtk or Qt use Xt, and therfore all the resource-related code and event
loops would need to be rewritten.
Yup, I was there at the time. The difference, now, is that XEmacs/w32
works. I.e., most or all the needed abstractions needed to have a
sensible integration of different GUIs are there.
Hmmm...
132 console-msw.c
239 console-msw.h
313 device-msw.c
421 dialog-msw.c
665 dired-msw.c
2805 event-msw.c
719 frame-msw.c
1903 glyphs-msw.c
79 glyphs-msw.h
789 menubar-msw.c
43 menubar-msw.h
1233 objects-msw.c
51 objects-msw.h
1493 redisplay-msw.c
306 scrollbar-msw.c
62 scrollbar-msw.h
180 select-msw.c
624 toolbar-msw.c
12057 total
163 balloon-x.c
282 console-x.c
492 console-x.h
1762 device-x.c
276 dialog-x.c
2803 frame-x.c
4294 glyphs-x.c
106 glyphs-x.h
628 gui-x.c
82 gui-x.h
815 menubar-x.c
1035 objects-x.c
67 objects-x.h
2337 redisplay-x.c
760 scrollbar-x.c
75 scrollbar-x.h
799 toolbar-x.c
16776 total
374 console-tty.c
301 console-tty.h
228 device-tty.c
268 event-tty.c
256 frame-tty.c
391 objects-tty.c
52 objects-tty.h
1553 redisplay-tty.c
3423 total
<sky kind=blue version="21.1 or more">
We should probably regroup everything non-portable in bigger
function-oriented files. Like GUI, filesystem, etc... If we tend to
make clear and documented interfaces portability will be easier
between unix and NT (and MacOS X, BeOS, etc... :-).
Actually, if you have a clean interface on which to write the support
for another OS/GUI/etc, the probability for someone to go and do it is
much higher.
</sky>
OG.
4:17 p.m.
New subject: toolkit wars again
And I will help you. We need to mess with more toolkits like we
need a shotgun blast to the knees. In order to get somewhere you
have to leave things alone that are already working. We need to
lose this inferiority complex about ourselves and our code.
8:34 p.m.
New subject: toolkit wars again
On Tue, Jun 09, 1998 at 11:17:07AM -0400, Kyle Jones wrote:
And I will help you. We need to mess with more toolkits like we
need a shotgun blast to the knees. In order to get somewhere you
have to leave things alone that are already working. We need to
lose this inferiority complex about ourselves and our code.
Prithee, tell me where you want to go ?
GUI and system abstraction is, I personally think, a worthy goal. It
opens the door to easy ports to MacOs X, BeOS and whatever other
environments someone may want to play with[1].
Now, if you have other goals you think that are more important, please
do share them with us. Really. I mean it.
OG.
[1] No, not my old 1040STF though :-)
11:19 p.m.
New subject: toolkit wars again
Olivier Galibert writes:
On Tue, Jun 09, 1998 at 11:17:07AM -0400, Kyle Jones wrote:
> And I will help you. We need to mess with more toolkits like we
> need a shotgun blast to the knees. In order to get somewhere you
> have to leave things alone that are already working. We need to
> lose this inferiority complex about ourselves and our code.
Prithee, tell me where you want to go ?
A compiler for Lisp code that produces C code. Display improvements,
like text that wraps around images, pixel-based scrolling, background
color transparency in more image types, subwindow support, beveling
as an extent property. Worthwhile FSF Emacs features like indirect
buffers. My goal, when I'm not fixing bugs and making XEmacs run
faster, is to make incremental improvements to what we already have.
GUI and system abstraction is, I personally think, a worthy
goal. It opens the door to easy ports to MacOs X, BeOS and
whatever other environments someone may want to play with[1].
I agree that this is a worthwhile goal. But that isn't what was
suggested. What was suggested was ditching the Lucid code what we
have now and replacing it with something else. Even if we keep
the Lucid stuff, is supporting another toolkit under X worthwhile,
when we already have functional menus and scrollbars? What would
we get out of this as a reward for the work and misery?
4:24 a.m.
New subject: Projects ideas
On Tue, Jun 09, 1998 at 06:19:35PM -0400, Kyle Jones wrote:
A compiler for Lisp code that produces C code.
I'm not sure if it is the right approach. A JIT using the bytecode may
be a better option, especially since there is a lot of work going into
that area nowadays.
Display improvements,
like text that wraps around images, pixel-based scrolling, background
color transparency in more image types, subwindow support, beveling
as an extent property.
I think aiming at something able to render efficiently XML/CSS2 kind
of documents would give us enough bangs to make a word equivalent. You
can even have vertical text :-)
Worthwhile FSF Emacs features like indirect buffers.
There are hints of that in the buffer code. Is it what is needed to
support multiple modes in the same buffer ?
Even if we keep
the Lucid stuff, is supporting another toolkit under X worthwhile,
when we already have functional menus and scrollbars? What would
we get out of this as a reward for the work and misery?
- Gnome and/or KDE integration
- Real dialog boxen. Replace, for instance, should not use the
modeline when invoked from the menu but create a nifty dialog box.
- Eventual ditch of the infamous Lucid stuff. Or will you implement
teardrop menus, detachable toolbars, themeable widgets elements,
etc... ?
You will have a *lot* of work if you want lwlib to reach the level of
what is expected from toolbars, menus and scrollbars nowadays.
OG.
4:29 p.m.
New subject: Projects ideas
Two more bedmates for the orgy. What are they bringing to the party?
- Real dialog boxen. Replace, for instance, should not use
the
modeline when invoked from the menu but create a nifty
dialog box.
I'm in the camp that says this should be done with ordinary frames.
Then you don't have to hack dialog box for every operating system, or
live with the limitations of a particular OS/library implementation.
The "beveling as an extent property" is part of reaching that goal;
it makes putting buttons into buffers possible without gross hacks
like xpm-button.el.
- Eventual ditch of the infamous Lucid stuff. Or will you
implement
teardrop menus, detachable toolbars, themeable widgets elements,
etc... ?
I've mostly implemented detachable menus. Some modest changes
are needed in the widget code. I've implemented a detached
toolbar. I'm not sure what themeable widget elements are, but if
it's anything like color schemes under Windows, it's nothing to
sweat over.
You will have a *lot* of work if you want lwlib to reach the
level of what is expected from toolbars, menus and scrollbars
nowadays.
I don't know about that. Our users seem pretty happy.
5:47 p.m.
New subject: toolkit wars again
> > Do you think we should aim at removing it
>
> Yes.
>
> > (using motif/lesstif, gtk, Qt, whatever (all of them ?)) ?
>
> Motif/lesstif no. Gtk or Qt (or both if the Qt licensing weren't so
> fucked) are preferable.
Well, we talked about this before... The big problem is that neither
gtk or Qt use Xt, and therfore all the resource-related code and event
loops would need to be rewritten. I for one would be more interested
in spending the time to really understand/rewrite/cleanup lwlib than
deal with the other headaches. I *like* the look and feel of lwlib
(if a couple of minor nits could be worked out of them). After my
current round of windmill tilting is done, I'll have a look at them.
I'd like to keep them, so I guess I'll do the maintaining.
And I will help you. We need to mess with more toolkits like we
need a shotgun blast to the knees. In order to get somewhere you
have to leave things alone that are already working. We need to
lose this inferiority complex about ourselves and our code.
9665
days inactive
9666
days old
8 comments
4 participants
participants (4)
-
Andy Piper -
Jareth Hein -
Kyle Jones -
Olivier Galibert