[sldev] gtk Q

[Glen]

I know of no strictly OGL toolkits, so changing to one is kind of a lost 
cause ;P

However, SL essentially has its own toolkit already written. All it 
really needs is a few widgets re-written, it seems. If I'm way off base 
then so be it; I'm not familiar enough with the viewer code to make that 
kind of judgment, nor am I familiar enough with gtk. Personally, I think 
if mozlib requires gtk, then SL requires gtk. Reinventing the wheel and 
writing a new SL-centric browsing engine to do the same thing is too 
huge. Maybe a webkit you're talking about would fix that. I really don't 
know.

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. Probably 
a huge job, and not one that is likely be very high on anyone's wish 
list. I'd originally looked at the build requirements and one of the 
things that makes it difficult for me - as a beginner with the viewer 
code - to compile my own is the fact that the dependencies are so heavy. 
So, removing the dependency on outside parts, i.e., gtk for one, would 
be a good thing. Lesson in contradiction, haha.

Though, if it were to be done, would it be a welcome thing? And does the 
gecko engine require gtk by itself, or just this implementation of it? 
Millions of questions surrounding that.

FYI - gstreamer works like absolute *crap* on my system. It's bad, 
really bad. Can't play video, period. Yes, all codecs and plug-ins are 
installed from the Ubuntu repositories. Yet, the SL viewer never does 
anything but crash when I attempt to play video media. Alternative 
back-ends are a Good Thing(tm). Xine seems to have no issues. It's not 
phonon doing it; it crashed when I was running a pure gtk-Gnome Ubuntu 
so I was hoping with phonon it would clear up, but no dice. The only 
common element is the presence of gstreamer and SL. Ripping out the 
gstreamer-only dependency for media would be absolutely fantastic for 
this reason, for me at least. So.. there goes glib and gtk, both, with 
the exception of the browser.

I dunno. I'm rambling and thinking out loud with it. I do entirely 
believe that using a solely SL UI toolkit might solve (and prevent 
future recurrence of) a few issues such as VWR-10136, and once it's 
fully 64-bit un-screwed, one can make a 64-bit build without requiring 
32-bit compatibility libraries. That should be a roadmap goal I think. I 
suppose what I'm actually getting at is that imo it would be easier to 
actually get into coding with the viewer if everything that doesn't have 
to be platform-specific, wasn't. I'm rambling and this is a book.

Require mozlib, SDL, and OpenAL!

Maybe I should write up a file chooser first. Color pickers are harder.

--GC

Robin Cornelius wrote:

> On Fri, Dec 19, 2008 at 12:50 AM, Glen <gcanaday at gmail.com> wrote:
>   
>> Ah, ok. the moz + gstreamer stuff would not be so simple to re-implement to
>> remove the gtk dependency. I'll scratch that off my potential project list.
>> Too big for me.
>>
>>     
>
> Mozilla may end up solving itself if webkit or some other replacement
> for llmozlib's engine happens. And gstreamer should only be using Glib
> so the rest of Gtk could go just leaving the glib library.
>
> What was your proposal for changing the tool kit? It might still be
> worth pursuing? any reduced dependencies could be a good thing.
>
> Robin
>
>