true that. It's been a crazy week. and yes I was getting everything
jumbled in my brain and mixed up with cocoa, which incidentally did not
have any rum in it. Probably the problem...
Though the special preprocessor makes cool stuff possible, like the
signal / slots mechanism. I would never suggest that there be a qt port,
no matter how cool it be. Simple requirements :D
though right now it's NOT compiling >:[ gtk / gst issues. WHY it can't
find it I have no idea. It's ridiculous. All of the requirements are
installed.
卡库拉迪 wrote:
Object-C? We're not dealing with Mac OS here, GTK is based on plain C
and GLib object system. And Qt needs a special pre-processor...
Although my preference of GTK over Qt is also a religious thing
(especially considering I've coded with neither) too.
Geneko
On Tue, Dec 23, 2008 at 3:22 PM, Glen <[email protected]
<mailto:[email protected]>> wrote:
I prefer QT to GTK because I'm none too fond of obj-C. That's a
religious thing, tho.
Why not improve the input handling in SDL?
And ahhh, I didn't know LL were taking the code elsewhere. No, I am
not planning to nor do I have any wish to use anything other than
the standard LL-coded viewer. Maintaining version compatibility with
a moving target is a nightmare and I won't attempt it. I've done it
before, and I have to say that I absolutely refuse to ever fork
another large OSS project ever again ;P Patches against LL code yes,
separate and soon to be incompatible code branch that is likely to
undo bug fixes I code, no. Oh my, no.
--GC
Alissa Sabre wrote:
Glen:
what is gtk actually used for in the Linux version
of the viewer?
Tofu:
Right now, file dialogs, color-picker, warning dialogs,
mozilla+gstreamer event queues, and copy-and-paste.
Three things on the point.
(1) Yes, there is a GTK-based color picker, but is is not usually
used. The default behaviour in today's viewer is to use LLUI-based
SL's own color picker. "Edit > Preferences > General > Use default
system color picker" controls it. I guess you can simply
disable the
GTK-based color picker.
(2) I believe clipbard operations are currently handled through Xlib
and GTK is not used for the purpose. See VWR-7036. Note that the
code that Tofu referred to as "The rewritten clipboard code by
Alissa
Sabre" in his comment on VWR-7036 *is* based on GTK...
(3) The warning dialog (OSMessageBox) is currently based on GTK, and
it is not straightforward to replace with LLUI, because
OSMessageBox()
may be called before OpenGL initialization (to notify some
unexpected
events, e.g., lack of some critical feature in the underlying OpenGL
implementation...)
But gtk is GPLd like the viewer is - so it would be OK to
port those widgets into SL's codebase and use SL's UI engine
to draw them.
If you are planning to create your own viewer distribution, that's
fine. However, I believe LL would never receive your patch if
you put
copies of GTK codes into the patch, because LL is selling the viewer
source to third parties under no GPL terms, and _importing_ external
GPL/LGPL codes into the viewer source will prevent LL from doing so.
Though, if it were to be done, would it be a welcome thing?
Some people welcomes it, and some other doesn't. You are free to do
so if you believe it is good. Nobody can stop you. That's the
great
feature of free software. Programming freedom. (Is RMS reading
this? :-)
My own opinion is just opposite. I've been trying to remove SDL
dependency from the viewer code, replacing it with a GTK-based
alternative. In other words, I'm _increasing_ GTK dependency. The
original reason I started it is to improve the input method
handling.
Clipboard improvement is just a (good) side effect. See
VWR-2261 for
details on this issue.
Alissa Sabre
P.S., I recently restarted working on VWR-2261 (after 1/2 year
blank),
and I'm uploading a revised patch soon, hopefully within this
weekend.
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated
posting privileges
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting
privileges
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
