Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Mozilla The Internet

QT Mozilla Port 204

Posted by CmdrTaco from the well-isn't-that-special dept.
LowneWulf writes: "Check it out! The Mozilla QT port has finally been checked into the Mozilla tree! Annoucement from the author here." The sad part is that I've switched to mostly using Konqueror these days. Less memory. Less crashes. Loads faster. AA fonts look better. Mozilla has a ton of excellent functionality that I look forward to getting in on (plus I've had a few compatibility problems with javascript and Konq). But its cool to see this coming along.
This discussion has been archived. No new comments can be posted.

QT Mozilla Port More

QT Mozilla Port

Comments Filter:

  • Re:mozilla (Score:1)

    by Anonymous Coward
    Use the <p> tag please

  • Re:Try Internet Explorer (Score:1)

    by Anonymous Coward
    I've been keeping a close tab on my Win2000 system since I first installed it a year ago......Internet Explorer Crashes?: I'm not sure

    Good working keeping the close tabs.

  • Wait, this one is even better (Score:1)

    by Anonymous Coward
    The sad part is that I've switched to mostly using Explorer these days. Less memory. Less crashes. Loads faster. AA fonts look better. Konqueror has a ton of excellent functionality that I look forward to getting in on (plus I've had a few compatibility problems with javascript and Konq). But its cool to see this coming along.
  • Just to be clear, TheKompany does not employ any core KDE developers (they do help out with koffice though) and they had nothing to do with kfm either.

  • Mozilla vs. Konq, development time... (Score:2)

    by Anonymous Coward
    I'm really just impressed with the rate of development for konqueror to Mozilla which just seems to be drudging a long. I'm a complete konqueror advocate, I just love the darn thing with the exception of some java script incompatibilites.. but thats being worked on immensly as we speak. The thing is stable, fast, small in memory and powerful. Why isn't mozilla? They've had probably more support and much more development time from what I've seen.. (Mozilla started April 1998? and KDE 2 development October 1999?) Is it the execution of the design or what? I'm not to bash mozilla, I think it's good and has a potential to be great but IMO it seems behind konqueror while it had the headstart.....

  • Re:Moz interfaces (Score:2)

    by Anonymous Coward
    Chris Blizzard at redhat ported mozilla to pure xlib at one point. I hope the work continues on that, since it is clearly bloat to map a library of widgets that you don't use (XUL draws its own widgets).

    The Qt version looks identical to the GTK+ version, since neither use the toolkit's widgets, they just use it for low level drawing code.
  • What if (on the Win32 platform) I don't want AIM (or if I already have it installed)?

    OT: Can anyone point me to a URL to get java working on Konqueror? I've tried several JREs, none seem to work (or I'm screwing up a setting somewhere).

  • It's all done by macros; very little programmer intervention is required.
  • When IE6 comes out in, like a year from now, it will be the browser we should have had four years ago.

    Well the problem is that there's still no other browser that is even close to being what we should have had 4 years ago. Netscape/Mozilla is a total mess. What's the point of having 10MBps of bandwidth when the browser takes several seconds to render a page. Not to mention the fact that Netscape is far worse on adhering to standards and adding it's own little tags.

    Lynx and w3m, etc, may or may not be more standardcompliant, but I'm sorry, I don't want a text-only browser. Konqueror is, admittely quite ok, but has a far way to go, it still crashes on quite a lot of pages. IE6 on the other hand, which I'm running right now, renders quick as lightning, hasn't crashed on me once, and has lots of nifty little features. Yes, ok, I does take up 12MB of ram, but virtually no CPU time, and it's still a lot less than Netscape ever did on my Linux (where it also crashes all the time). (And don't give me "it's builtin to the operating system" - I don't care, in a modern OS internet SHOULD be tightly integrated. It's the Right Thing (TM) in my opinion).
  • What was your point on my comparison? I compared a beta browser to a non-beta; yepp. So? I could have compared IE5.5 to the lastest konq release if you want to? I would say the same things. And yes, Konq does render nicely, and has lots of little nice features, but it crashes for example on http://tvprogram.nu which I use > 10 days a day to see what's on TV. It's also crashed repeatdly on other sites. And I'm sorry, but a browser I can't use for my everyday work, isn't a good browser in my book.

    And yes it possible that Konq is more integrated, for which I applaud them! In all fairness I think KDE2 is the only sensible desktop project on Linux. I've used Linux since 93, but nowadays I'm older, and wants stuff done, and have no energy for fighting my OS at every step. Win2k does everything I want (including emacs, a nice prompt and Counter-Strike) while being just as stable as my Linux, and having a much nicer GUI (== more consistent).
  • Every other browser, especially Netscape, out there basically does this too. The few good ones that doesn't are Lynx, Amya, Galleon and so on. The reason you're redirected has been stated many times over, and by people not from MS. If you hate it that much, just change it? (Or delete the bookmarks, as I do, since I have no use for them.)

    IE might be a good browser, but I'm not going to drive a car with a locked hood that says 'Sponsored by Scientology', or something.


    But I bet you'll use an OS and apps you have no clue how they work and look in src, just because it's open source? Have you gone through the kernel and your apps line by line? Didn't think so. And the "Sponsored by Scientology", I didn't get all ... in what way is IE more "sponsored" than for example Netscape or Konq? They all come from a company or group that releases a browser for free, all saying basically "NO WARANTEE".
  • It was actually a while since I tried the latest Mozilla build, so I downloaded it (0.81) and tried. It sure looks and feels better than NS6 (especially the UI) but it still takes 40-80% more time than IE6 Beta Preview 1 to load and display a page. Sorry, but it's not that great yet. (Tests highly informal).
  • How does one enable GTK look-and-feel with Mozilla and/or Netscape 6? I had it working and then upgraded to v6.0.1 and deleted my old ~./mozilla directory... D'ohhh!
  • Well, under Linux it was dependent on GTK+. Thanks for playing, though.
  • Well, the *n?x port is dependent on gtk+. It was already dependent on a toolkit; this port simply makes it dependent on a different toolkit.

    Build instructions for Unix [mozilla.org]

  • Well, the slashbots seem to be trashing Malda for talking up Konq, since it's not cross-platform...wow, IE runs on a whopping, what, one platform too? Oh, I suppose I'll count the Mac port, even though it sucks ass. Heck, konq has it beat there, as it's already on more than two hardware platforms.
  • Damn, wish I had some moderator points to mod you up with. Either people don't get it, or people who post such things ("you Linux zealots should stop bashing MS so much") are in the employ of Microsoft, or both. MS's marketing dept., yes, does post more pure garbage than the average horde of Linux devotees. :-) (BTW, anyone notice the increase in crap floods after the Miller "Linux is going down" announcement?)
  • Feh, no thanks. I'm running Konqueror 2.1.1 right now. It sounds like you're comparing a beta Microsoft browser to the current release of Konq. At least have the decency to compare IE6 to the current Konq. :-) I have a K6-300, only 64MB of RAM, and hm, Konq renders quick as lightning, hasn't crashed on me once, and has lots of nifty little features. And yeah, it's integrated into the desktop environment pretty well--better, I think, than Microsoft's IE on Windows. (BTW, unless they've changed things for IE6, IE really isn't part of the OS, despite the noise they made during the antitrust trial.)
  • Well, yeah, I failed to point out the different OS platforms Konq will run on. I've been a FreeBSD user, it's ! Linux, in some ways, it's > Linux, but I'm curious as to why you're flaming me a bit. :-) The only issue I have with Konq is the braindead Netscape Flash plugin, though you've probably not had to deal with that as that'd be a pain (iirc there's no FreeBSD plugin, just Flash through Linux emulation on Linux Communicator?)
  • It's already been done for some time with GTK-- it's called Galeon [sourceforge.net]. I used it a while back and it worked pretty well. It really did strip out a lot of the "extra" stuff, and seemed to speed it up a bit, although not as much as I would have hoped. As others have mentioned, it would probably require more than just a toolkit makeover to really speed up 'zilla.
  • While it somewhat defeats the purpose of having widespread public releases for debugging, have you tried stripping the debugging info from mozilla?
    Running 'strip' will knock quite a bit off the executable and it runs quite a bit faster, you just lose the ability to trace where any crashes come from.
  • That's a pretty bad analogical argument. Microsoft's implementation and changes to Common Internet File System (CIFS), the supposed real name for what everyone refers to as "Windows networking," is a pretty different issue from a standardized content viewer.

    Does Microsoft have an amazingly non-standard TCP/IP stack? There are standards that must be followed, and if there is a standards body that is actually listened to in a field, eventually Microsoft will come around.

  • Legacy bloat in a product which has never been released?

  • Uuh I dont think so I'm using mozilla, and i'm seeing the popup lists with little scrollbars in my gtk theme, so they must be using gtk for more than just 'low level drawing'. sure, its not used for menubars, back/forward buttons and the browser scrollbar, but have a look at the buttons, lists, etc IN the html page... those are gtk controls!
    Mozilla (and IE) render all GUI widgets except drop-down/combo boxes; Dropdown lists aren't rendered by the browser because they don't need to be (dropped down lists are not really part of a web page, like buttons and edit boxes)

  • Because they haven't optimized much (if at all) on Unix. Click on my username to find a more detailed post by me on the subject.
  • So when sourceforge and /. close due to lack of revenue what exactly are you planning on doing? That'll simplify your regexes a little bit, eh? Or will you be first in line to offer to pay for it? I'm not holding my breath.

    This isn't like TV, where watching or not watching a show or the ads doesn't impact the revenue stream of CBS, NBC, etc. Blocking /.'s ads directly impacts their ability to stay afloat and provide you with stuff that is worth reading (and in sourceforge's case, worth programming with or on.) I guess I know I'm not going to change your mind, but maybe it'll stop others from following the same path. Shame that /. has such a technically savvy userbase... if this is what people are going to do with their knowledge, it's going to cost /. in the long-run. Maybe they do need to start posting more Windows stories.
    ~luge

  • Re:Moz interfaces (Score:3)

    by luge ( 4808 ) <.gro.yugeit. .ta. .todhsals.> on Tuesday April 17, 2001 @09:05PM (#283531) Homepage
    Two points:
    1) What Moz wants more than anything else is to spread the renderer (and hopefully the plug-in model) as far and wide as possible. They don't care all that much about the chrome and all. If that spreads, great... but I get the impression that spreading the renderer is just as important if not more so. Hence, embedded apps (which includes not only "net appliances" but also QT, GTK, and (gasp) AOL) are a prime concern and they spend a lot of time making sure that embedded support is done correctly.
    2) I get the impression that QT is not actually "supported" in any meaningful sense. In other words, like the OS X and OS/2 ports, Moz puts it in CVS and provides ftp space and supports it in that way. But they don't actually support it in any meaningful way- i.e., programmer man-hours. In this sense, the QT and other OS ports are proof that Open Source has worked for Netscape- it has allowed others to come in and contribute, reducing cost and maximizing impact for Netscape.
    ~luge
  • The basic answer is that the 5% of the code that is not cross-platform is a lot of the most performance sensitive code in the product (graphics rendering, networking, file access, etc.) Mozilla/Netscape have poured tons and tons of man-hours into optimizing that code on Windows. Those hours (since they are in non-XP code) do very, very little for the other platforms. In contrast, they've put very little time or money into optimization on Linux and other platforms. Obviously, they've optimized the XP code as much as possible, but that only goes so far- the lowest level stuff is where a lot of optimization work has to go on, and that just hasn't happened on Linux yet. IMHO, optimizing that stuff is where old-school Linux gurus could be of the most help- learning the guts of Moz isn't easy, but that type of stuff is "just" X calls and things like that, where folks not very familiar with Moz but intimately connected to X and other common sub-systems might be able to make a quick and important contribution. Until there is both marketshare and serious competition in Unix, Netscape/Moz isn't going to do it for us.
    ~luge
  • Qt is C++. There are bindings to other languages.

    You're not going to change the entire object model.

    You can't just take code from Qt and put it in glib.

    If you can tell me a way to do this without an abstraction layer, I'll believe that you did not really mean abstraction layer.

    The idea is still worthless, and i think you should read the rest of the replies to your post.

    Is your head so far up in the clouds that you do not see the codebase in use already? Do you really expect everyone to change their code to match a new api? Keep in mind that there are people who use Qt and gtk commercially. Trolltech has a commitment to their customers to keep their API the same.


    -- Thrakkerzog
  • Aha! You mention an abstraction layer!

    Plbttth!

    :-)

    Hey look! These two languages are really producing machine code underneath.. why don't we merge the two?


    -- Thrakkerzog
  • Could you please explain exactly how GTK+ does inheritance? I don't get it.

    can I put a bunch of GTK+ "objects" in a list (of the superclass type), pull them out later on and call a method which does the apropriate action based on whatever type that object may be?

    Think of a list of "Drawing" objects. Pen, pencil, etc.. Each object inherits from the "Drawing" superclass. I put all sorts of pens and circles, etc on a list. Later on, I pull them out in a loop, assigning them to a variable of type "Drawing". I can then call Drawing::Paint() on each object, and it will execute the code of the appropriate object type. This works in C++, Java and Smalltalk quite easily.

    Given that C does not allow you to overload operators, I don't see how this can be done.

    Please enlighten me.


    -- Thrakkerzog
  • Oh, just so you know that this is really part of inheritance, there is the subclass rule, which is a big part of OO.

    Everywhere an instance of the superclass is used, a subclass of the superclass can be used instead.


    -- Thrakkerzog
  • Overloading is more than operators.
    Overloading is also re-implementing methods from the superclass, and having more than one method with the same name, but different signatures.

    You can not have two functions in C with the same signature. (Or two functions with the same name and different signatures!) So, from what you said, you can not have each GTK "subclass" have the same function name for whatever "methods" you bind to a GTK object.

    This means that you can _not_ use a subclassed GTK object anywhere the superclass GTK object is used, which breaks one of the fundamentals of OO.

    am I missing something?


    -- Thrakkerzog
  • Well, let's see..

    Qt is C++, and takes advantage of advanced c++ features such as inheritance. You can't exactly do that in C. (without a bunch of pre-processor crap)

    The entire object model is different. You could create a wrapper which is another layer of abstraction between the toolkits.. but most people don't understand that Qt is much more than a widget library.

    There is stuff in Qt today that will take some time to implement in gtk+ or glib. Why would you want an abstraction layer that couldn't do everything both toolkits have to offer?

    If you made an abstraction layer, you would use _more_ memory than before! The whole idea is worthless in my opinion.


    -- Thrakkerzog

  • It's a good idea too.

    I'm sure many other people are thinking the exact thing that you are - to do a feature map from GNOME to KDE and vice versa. Come up with a combined model, where people could target either GNOME or KDE by writing to one.

    It'd be nice if the component models could be made to work together as well, so that people could use the best of both worlds - but that would require some serious cooperation (I think.. anyway).

    Laxitive
  • If I were Steve Case, I'd be asking why they didn't just maintain Windows, Mac and Unix ports (keeping as much of the rendering engine cross-platform as possible) and make them each as good as possible.

    Building the interface in Javascript was certainly one of those "seemed like a good idea at the time" things. It bought them the ability to run on BeOS and OS/2, and cost them a responsive browser on their primary platforms (the Mac port is so retarded, not to mention already obsolete that it's really just Windows and Linux).

    A guy wrote the basic KMelon Win32 shell in a weekend - I figure if they put the XUL interface into legacy mode today (let the Be and the OS/2 people maintain it) and hired 3 engineers (GTK, Win32, Carbon) - they would have a decent, quick, professional, platform-consistant GUI done by Moz 1.0 in Q4 2001.

    Note that one of the big driving factors of XUL was to get Unix developers on board without having a widget war situation. (GTK was beta, QT was proprietary, the Freenix people hated Motif). With Big Unix on board with GTK, that's pretty much been solved, this topic of this article excepted.
    -- posted from Moz 0.81/Win32
    --
  • You can do that yourself with "user style sheets" - I remember to have read an article about it not long ago somewhere on Oreilly's website!
    Greetings Joergen

  • I had this problem when I had AA fonts enabled but had a corrupted font file. When it tried to read in the corrupted file it would crash. I could browse local files and run several KDE apps but when I tried to load a web page it would die badly.

    Try using strace to figure out what it is doing at the time it dies, and look at the KDE Crash debug output. Both can be very helpful.

  • I don't run KDE.

    I run Konqueror.

    None of KDE, QT, or Konqueror are in memory when I load it the first time.

    It loads faster than mozilla.

    It loads faster than netscape.

    I'm not a KDE zealot or a Konqueror zealot... Hell, I even hate QT; I think the widgets are unnecissarily large and ugly, too much stuff responds to mouse overs, and there is a general bubbliness about it that just bothers me. Konqueror gets the job done better then netscape and mozilla though. Konqueror gets the job done faster. The only thing that is faster is table rendering in mozilla, but everything else is so slow that it's an overall beast.
  • Konqueror, while a really cool web browser, has had just one goal: surf the web, on unix, on X, and on KDE2

    While I agree with most of what you said, I have to take exception to this. Konqueror also has the goal of being a file manager and viewer, and an excellent one at that.

    ALso, Mozilla is a lot more than a Web browser...it's also an e-mail client, HTML editor, news reader, chat client, instant messager, and so forth.

    Basically, its like comparing vi with Emacs. Both are text editors, but they have vastly diffferent goals...same with Mozilla vs. Konqueror, but s/text editors/Web browsers.
  • It's not hard to call C++ code from C. You just need to do a bit of wrapping..
    Just do something like this to avoid name mangling.. But to get back on the topic - what the hell are you talking about? It's true that c++ code needs to be linked against the c++ std lib, and equally true that the c code needs that too - but there's absolutly nothing stopping an app from linking both (there nothing stopping an app from linking both Qt and GTK+ either).

    I the idea given in this thread is certainly feasable - to write a GTK+ API like wrapper in C for Qt and a Qt like wrapper in C++ for GTK+ - just wrapping native calls to a new API so Qt programs could be written using the GTK+ api. It certanly isnt *easy*, but it's possible.

    class foo {
    public:
    void hi() { cout << "hi";};
    };

    extern "C"
    {
    void *makeFoo() { return new foo;}
    hi(void *this) { foo *f=static_cast<foo*>(this); f->hi(); };
    }

    Calling C from C++ is even easier.
    just extern "C" {} the C code.

    -henrik
  • It's *common* to write programs that are part C and part C++.

    You seem to fail to realize how insightful the question really is and get bogged into trivial details. Why doesn't QT allow me to compile GTK apps against it, or vice versa? is a very good question. There are C bindings for Qt and C++ for GTK. Making those bindings emulate the interface of the other lib is a large amount of work, but it's not impossibly big.

    Here's the kicker: It would allow the programmer to use what language/interface she prefers (GTK/C or Qt/C++) and the user to decide how he wants the apps to look and feel (Qtish or GTKish). Something like this would go a *long* way to unifying Gnome and KDE without sacrificing one codebase. The user can then decide if he wants the Qt or the GTK libs installed, but all apps will run with either one.

    -henrik

  • How to Fix Mozilla's Slowness (Score:4)

    by Phill Hugo ( 22705 ) on Tuesday April 17, 2001 @11:55PM (#283574) Homepage
    Firstly, mozilla isn't really "slow". Its a complex little beast. Its less a "web browser" and more an application framework with built in Javascript engine and cross platform GUI descriptor langauge (XUL).

    Practically the entire 'application' is built from XML and Javascript. That's why its so themable and is also why it is being used to develop cross platform applications (www.activestate.com - check out Komodo).

    To bypass the slowness, get Galeon. (galeon.sourceforge.net). The latest version is stable and is Just A Web Browser. You need mozilla installed as Galeon uses it as the HTML engine but none of the extra stuff (mail, news, composer) are enabled and it flies along really nicely.

    It very rarely crashes, copes with plugins and java perfectly (well, wherever I've tested that anyway) and has a really nice recovery mode which reverts to the open pages you had if ever it does loose its sanity (a very useful feature).

    It you want to know how good the vanilla HTML handling in Mozilla is, try it. You really won't be disappointed.
  • If your X server crashes, one of four things is true. These are given in order from most probable to least probable:
    1. You are running your applications as root like a wannabe sysadmin who's still wondering why "cp /home/stupid/*.* /backup/*.*" doesn't work under Unix.
    2. There is a bug in your X server.
    3. Your hardware is bad.
    4. There is a bug in the kernel.
    There are no other possibilities.
  • Regarding backspacing in the Location bar, check out the little black tag with the white X on it that's to the left of the word "Location" (at least on my installation).

  • Actually this is not new... (Score:3)

    by kjj ( 32549 ) on Tuesday April 17, 2001 @09:33PM (#283579)
    At least the concept is not new. There was something called QTScape done a very long time ago right when the Mozilla project first started. Of course back then the code was based on the old Navigator code and is completely outdated. Its good to know there is some work being done on this though. I think that using the QT toolkit good give Mozilla a significant speed improvement. I know that Konq. is fast as well but it would be interesting to compare the speed of these two browsers when they run on the same toolkit. I have a feeling that Konq. would still be a little faster but perhaps not by nearly as much. Plus Mozilla has many features that Konq. doesn't have.
  • Konq has great history, click on Window->Show Sidebar.

    I also am unable to get HTTPS to work on Sparc Sun Solaris. Perhapse there is an endian issue?

    As for speed and stability, it feels much faster than Netscape, loads much faster, and usually renders better. It's also more stable. I havn't played around with Mozilla on Solaris.

    This was posted with Konqueror
  • I was emailing a web authoress just yesterday, about how Konqueror's presentation of her ... well, `really bad' HTML is the only thing to call it, and offering help, info, etc. She wanted to know what Konqueror was, what she'd been doing wrong, and thanked me much for the philosphical and tehnical background, and started fixing the site.

    I wish all web creators were so open to helpful criticism... I find it interesting that it tends to be the amateur, in any field, which has what's usually called a professional attitude...

    Anyway, not to say you're wrong about the lack of backlash as such; but this was the first time in years I heard back `I tried it in Messie and Nessie' without it being followed by some snarky `get a real browser'-ilk remark. Is the struggle worth making? Can we win? who knows... but I figure there's getting to be some, let's say, non-fringe competition in user devices, especially handhelds, and recognition of access issues, which might show there's money to be made by compatibility instead of in-. Cross our digits...

  • I think that would be kinda stupid. Annoying ads are not always that size, and some useful graphics happen to be that size. A URL filtering proxy is a much cleaner solution. Very effective, for me, just setting 4 URL regexes have, for me, essentially eliminated ads, fmads.osdn.com, ad.doubleclick.net, images.slashdot.org/banner, and adtegrity.spinbox.net. Whenever I find a new banner ad, I just add the ad site URL in, and it goes away. I still get to see the 468x60 images I have an interest in, and don't get annoyed by certain non-standard ads/pop-up tricks ads pull. Of course, I use galeon tabbed interface to minimize pain of pop-ups as well as my junkbuster proxy which forwards all requests through a squid cache before going out. I know there are cleaner ways of doing this, but it is effective and easiest this way.
  • As near as I can tell, the culprit seems to be the hugely bloated chrome interface. Use a project such as galeon, which embeds the mozilla renderer in a decently fast UI, and things seem much better. Pretty stable too.

  • Konqeuror (Score:3)

    by Junta ( 36770 ) on Tuesday April 17, 2001 @08:25PM (#283587)
    Seems like a great browser, but when I installed KDE 2.1.1 and loaded up Konq, I couldn't try to load any web page without it crashing. Is this common, or just an oddity for me. It really annoyed me, was looking forward to trying it out. Galeon works like a charm however, and plain mozilla is too sluggish to pay any attention to whatsoever. If netscape 4.x wasn't so ugly viewing a lot of pages nowadays, it would still be my browser of choice, it still seems to render faster than any mozilla-based project. Can't wait to see a Mozilla 1.0 with all the sluggish debugging ripped out. I wish there was a branch where debugging was removed just to show off what mozilla could be capable of. Maybe then we wouldn't criticize that so much.
  • Correction:

    img[width="468][height="60"] {-moz-opacity: 0.1}

    (make image translucent)

    img[width="468][height="60"] {display: none}

    (make image disappear completely)
  • I'll say it again: why close your browser?!

  • You have it wrong (Score:3)

    by Betcour ( 50623 ) on Tuesday April 17, 2001 @09:45PM (#283593)
    Oddly enough, as times pass and IE gains market share, it gets MORE standard compliant than it ever was. The new IE 6 even goes as far as not being compatible with IE 5.5 and below so that it is more strictly compliant with HTML 4.0, XHTML and CSS 1 & 2 (don't worry, there's a switch to drop the compatibility mode and use the strict standard mode, the compatibily mode being run by default).

    One good thing with the lack of competition in browsers is that Microsoft doesn't feel the need to divert from the standard and introduce new funky tags. I'm not saying this won't change to something worse, or that we won't see "Windows only" functions spring back to life, but for now IE 6 is the most standard compliant browser ever, while being the one who face the smallest competition ever.

    Please before flaming me go read the IE 6 preview papers first...

  • Re:Hey! (Score:3)

    by Dwonis ( 52652 ) on Wednesday April 18, 2001 @08:08AM (#283594)
    I'd just like to step in and tell you that "Amiga weenies" are the most loyal, intelligent, and mature computer users I've ever known. They support the best technology. Period.
    ------

  • Good question in "talkbacks" (Score:3)

    by 1010011010 ( 53039 ) on Tuesday April 17, 2001 @07:19PM (#283595) Homepage
    And that question is:

    Why is Mozilla so much slower on Unix than on Windows?

    And I have a question of my own to ask:

    Can the "chrome" be scraped off of Mozilla, and replaced with GTK/QT/whatever?

    - - - - -

  • Re:Good question in "talkbacks" (Score:3)

    by cobar ( 57479 ) <maxwell@101freeway.com> on Tuesday April 17, 2001 @11:00PM (#283596) Homepage
    It appears that the real problem may be with how gcc and mozilla are interacting. Please see this status update [mozilla.org], in which it states that gcc is generating code that is twice as large as what Visual C++ is generating. If Linux builds are executing twice as many instructions, of course the Windows builds will be faster. Further follow-ups don't show much progress other than that switching from egcs to gcc 2.95.2 [mozilla.org] reduced size by about 5%.
    Unfortunately, using gcc 2.95.2 requires a libc upgrade [mozilla.org]. I just installed the gcc 3.0 3/20/01 snapshot and am going to try a build tonight to see if it makes much difference.

    Since pavlov was moved to help out with libpr0n, I haven't been seeing many updates about general Linux performance. Back in November thru early January, this was one of the main things the Footprint team was working on. pavlov seemed to be one of the most knowledgeable guys in the area and there were several people assigned to it. It seems they all got pulled elsewhere.

    To really make Mozilla work well in unix, they need to put the focus back on speed and also take a look at the memory leaks that plague the linux version. After browsing for a few hours, Mozilla tends to swell up from around 20 megs of ram to 50 or 60. They had some graphs profiling this problem, but those seem to have stopped being updated as well.

    On the whole, I find Mozilla pretty darn useable at 0.8.1. I run it on Linux and FreeBSD (under linux emulation so I can use the flash plugin) and it barely ever crashes -even when subjected to the massive javascript porn popup stress test.
  • Personally I don't care how different they choose to make the underlying code. What i'd like to see them do is standardize on one appearance system. In Windows people don't know whether they apps they wrote were done in pure API calls, MFC, VCL, or whatever else. And it's usually not readily apparent what language was used. A toolkit is different than the class libraries under Windows, but the idea is the same, people would care much less about QTvs GTK+ vs Motif is the apps supported a single drawing style and theme system. The code to layout the window doesn't have to be approached the same way, so a QT widget is fundamentally different from a GTK widget. Only thing changed is that they now look the same to the user.
    treke
    Fame is a vapor; popularity an accident; the only earthly certainty is oblivion.
  • http://www.muhri.net/skipstone [muhri.net], it's a pure GTK+(No gnome libs) browser using the Mozilla renderer
    treke
    Fame is a vapor; popularity an accident; the only earthly certainty is oblivion.
  • Qt is C++,

    Actually, its Python. No wait, its...just about every other language it can handle. Since one can't do inheritence in C, make it suitably modular.

    The entire object model is different.
    Yes, we need to fix that.

    There is stuff in Qt today that will take some time to implement in gtk+ or glib.
    I know. Lets get started now, if glib seems to be the best place to put that kind of thing (I think Qt might be)

    If you made an abstraction layer, you would use _more_ memory than before!
    Did I ever say *anything* about an abstaction layer?

    The whole idea is worthless in my opinion.
    That's because you currently don't seem to understand it.
  • Merging them would create a toolkit that is
    something very different from either one

    Ideally it should resemble both and not be too difficult, or provide a common layer between the two, much is the same way that Win32 provides a layer beneath MFC and VCL, which were once two very distinct toolkits.

    the apis are very different for both toolkits.
    I should have mentioned I'm talking about merging the API as well as the toolkit.

  • QT and GTK are fundamentally different toolkits, operating on different programming paradigms

    Could you elaborate? AFAIK they can both handle, C (GTK native, Qt C bindings), C++ (GTK using Inti, QT native), and Python (Python bindings for both.
  • QT and GTK use different langages (C vs. C++)

    AFAIK, no. GTK can do C++ using Inti. Qt (I hope) also be bound to C. Both have Python bindings.

    If this came about, what would be the point of having 2 toolkits anyway?

    There wouldn't be, as a reasonable set of functionality from both would be in one combined library

    Why don't we all just switch to Win32 programming and use WINE?

    Because Win32 is not Open Source, controled by MS and is broken according to some.

    One toolkit is better than 2, right?

    Only if that one toolkit is well written, modular, and has little overhead.

    KDE can import your GTK+ and IceWM themes, making "lack of constant appearance" a matter of user choice.

    if you're speaking about KDE / GNOME (semi OT), no. It is not reasonable to expect a user to learn 2 sets of common dialogue boxes, 2 sets of widgets that react in 2 seperate ways, ad infinitum

    What lack of consistency in UIs? Buttons, scrollbars, checkboxes, radio buttons, dockable toolbars - these concepts are almost identical in both toolkits. The only difference is in their appearence (KDE puts two buttons at the bottom of a scrollbar, but only in some themes, etc - this would be solved by QT importing GTK themes).

    Making GTK compile QT apps (even though it's really impossible)

    You think GTK can't do C++. That is incorrect. It seems you think this is impossible based on that idea.

    Having GTK compile Qt apps would not help the stability, speed, or functionality of the Windows port of GTK,

    Actually, I was thinking of having Qt compile GTK apps, as it seems to be the more well developed and cross platform of the two, seemingly due to age, though others with more knowledge might have a better idea. I think it would, as QT has been dedigned to be cross platform (including non Unix-like OSs), but again I'd like to hear from someone with experience. After the GTK = C comment, I'm sorry but you don't count.

    With QT-GTK and GTK-QT widgets almost ready and XParts in the works, programs for either toolkit can use widgets or components (think Parts/Bonobo) from both.

    That's great news. But a single object model would still be cleaner.

    The idea doesn't take away anyone's freedom to choose - you could still use whatever toolktis functionality was duplicated into the other to form the newer kit.
  • Qt is C++. There are bindings to other languages.

    Why should this be the case (seriously, my eyes are open to options for those who explain themselves reasonably)? In thirty years time, will C++ still be the most popular development language? Shouldn't these toolkits be modular?

    You're not going to change the entire object model.

    A massive change isn't it? But greater ones have been affected. Hopefully it should be possible to migrate it over time.

    You can't just take code from Qt and put it in glib.

    I know. I'm not proposing to use either as they currently stand, but create something that's language independent.

    The idea is still worthless, and i think you should read the rest of the replies to your post.

    I'm reading every one, positive or otherwise, with an open mind, and responding with questions where I need to. I've never called an idea or another poster worthless yet.

    Is your head so far up in the clouds that you do not see the codebase in use already?

    You've overly abrasive, but I do get the point. But I think the current code base is miniscule in proportion to the future codebase, and a stable modular toolkit which doesn't rely on a particular language would be a good base to build on. The thirty years bit...

    Do you really expect everyone to change their code to match a new api? Keep in mind that there are people who use Qt and gtk commercially.

    Indeed. Over time yes, just as they would eventually change to a new release of either of those two toolkit / APIs.

    Trolltech has a commitment to their customers to keep their API the same.

    They have a commitment to their customers to keep the API in a forward moving direction without significantly breaking compatibility with previous releases. Just as the people doing commercial GTK support have similar commitment. There's a big diff there.

  • You do not seem to understand the difference between a language binding and native support of a language. They're NOT the same thing.

    I should have raised this earlier, but I see no reason why a particular tooklit or API should be more accessible to one language or another.

    Win32 isn't open source, but WINE is, and WINE is an implementation of Win32.

    Yes, but Win32s future is controlled by MS. Wines future is dictated by Win32 future. Furthermore, Wine is a work is progress, and there are very few stable apps I've seen that use it (as a Corel WPO2K user, I'm pretty sure about that one). MusicMatch, Websphere HP builder, and especially WP02K have serious issues.

    I see no concievable benefit in merging them.
    What do we get? Consistent look and feel? Already got it (theme importer).

    Consistent look and feel =! theming! Please understand this! Its dialog boxes, widget behavior, panel application behaviour, drag and drop behaviour (xdnd still isn't used properly by either Konq or the GNOME desktop - try it with Konq FTP sometime).

    Because of this, end users are forced to choose their apps on toolkit compatibility rather than quality. That is a Bad Thing.

    To be honest, in terms of KDE / GNOME (which this discussion seems to have been moved towards) I would actually be just as happy if KDE and GNOME worked properly together now. But they don't. Not by a very long shot. For all the reasons above, and a billion more (duplicate menus, bookmarks, config centers, etc), and it seems very few people care.

    Interoperability? Already got it (QT-GTK widget and XParts).

    Good point, but they're both unfortunately very rarely used.

    Might as well start a whole new toolkit, QTK or something.

    Um, yes. That's what I'm talking about.

    My understanding of the current QT licensing situation were that someone could port the Linux version of QT to Win32 to create a GPLed Win32 QT. Anyone care to correct me?
  • an ideal world, it would be like this.
    yes it would :-D

    we're getting more OT. I thought you weren't talking about KDE/GNOME,

    I was responsing to someone who was. And by responding to you, we're even more off topic. Great isn't it? I'm very well aware all these things are provided by the environment, as you surely know. Oh well.

    That just shows that you don't read the KDE or GNOME mailing lists.

    True. But I do follow their news and kernel cousins and had a good chat to a couple of CompanyX employees about this issue at a conference recently. Their attitude was that one (either GNOME or KDE) would become massively larger than the other and interop was of very little long term concern. This is what worried me.

    The duplicate Control Centers and such are not a problem - just don't use the other one!

    Um, how can I not use the other control center? Remember, I'm picking apps based on quality, not toolkit. In this case, that's Gimp, Konq etc. Can one of them configure both these apps?

    You seem to have switched gears now from "lets merge GTK and QT and keep compatibility" to "Lets create a whole new toolkit".

    My basic tenet was to create a modular project with the best elements and bindings of both. Good Open Source apps re--use code whenever possible so most `new' apps borrow heavily from old ones.. Whether the first line of code is original or taken from another project is of little concern.
  • Because they are different libraries.

    That's obvious enough - as is that I'm not talking about the present situation, but a future one.

    A combined API and toolkit that's modular in design and language independent (for the next big shift in language design that replaces C / C++), with a superset of features from both, with a spec created by a neutral third party.

    And yes, that is a lot of work.

  • Here's an idea (Score:4)

    by Nailer ( 69468 ) on Tuesday April 17, 2001 @07:11PM (#283607)
    Why can't I compile any app with QT support?
    More to the point, why doesn't QT allow me to compile GTK apps against it, or vice versa?

    Remember X2 and K56Flex? No? They were two different 56k modem standards. Both groups expected their implementation to be ratified by the International Telecommunications Union, who were going to analyse the points of each and decide of a 56k standard.

    In the end, the ITU decided that both standard had their good points. V90, a standard that took the best bits of K56Flex and X2 and combined them into a single standard, became the order of the day. And the crappy X2 / K56Flex incompatibilities died a graceful death.

    Could an independent group such as LI do the same to GTk and QT? This would solve...

    1) Wasted memory.
    2) Lack of consistent appearance.
    3) Lack on consistency in widget behaviour.
    4) Some of the lack on consistency in UIs, but not much.
    5) Lack of solid cross platformability for particular toolkits. I am told GTK for Win32 is not the best right now. A solid cross platform Unix-based / Windows toolkit would help Open Source Unixes a great deal
    6) Limitations of widget availability between both toolkits.

    Please bear in mind this is a completely different concept to merging KDE and GNOME, which have less to do with Qt and GTK than many people think.

    Thoughts anyone?
  • It works with some site's banners, but not all. For example it works with megatokyo [megatokyo.com] but not with slashdot [slashdot.org]. I suspect that the style sheet is overridden on sites that use style sheets. Is there any way to prevent this?

  • Re:Mozilla vs. Konq, development time... (Score:5)

    by dimator ( 71399 ) on Wednesday April 18, 2001 @12:47AM (#283609) Homepage Journal
    You can't really compare these two as projects, because they have completely different goals. Mozilla has to work on 3 different platforms. When Mozilla was started, there was no mature widget set that they could use for the Mac, Win, and *nix, so they had to build their own (in the form of XUL/JS) while they were building the app that used it! (Also note that this UI system was built optimized for Win32)

    The Mozilla project is also focused on embedding their layout engine into other products, such as the upcoming AOL for linux release. They've also built a really nice email client too, which is on-par with most other free email clients, such as outlook express.

    Konqueror, while a really cool web browser, has had just one goal: surf the web, on unix, on X, and on KDE2.

    Side note: due to the excellent design of both these projects, we can now expect a mozilla KPart, that we can use to browse the web through konqueror using the mozilla layout/js engines, very soon now! I think it's already in the works...


    --
  • QT and GTK are fundamentally different toolkits, operating on different programming paradigms. Merging them would create a toolkit that is something very different from either one, which essentially means starting from scratch with a new toolkit.

    If you mean from a compilation standpoint, why can't GTK apps be linked against QT, and vice versa, this is fundamentally impossible; the apis are very different for both toolkits.
  • Blocking /.'s ads directly impacts their ability to stay afloat and provide you with stuff that is worth reading (and in sourceforge's case, worth programming with or on.)

    Well now, that depends.

    I use junkbuster to block most ads. The reason for this is simple: I'd prefer not to see them. Why? Because they don't interest me. And that's the key point right there. They don't interest me. It doesn't take a lot of logic to deduce that, even if I weren't blocking them, I sure wouldn't be clicking on them. After all, they don't interest me.

    It just so happens that set up junkbuster to let Slashdot's ads through. Why? It's not that I'm trying to be a good citizen. It's because they interest me. I want to see what TMBG's up to. I want to see what ThinkGeek has new this week. Not only do I view these ads, but I click on them. Because they interest me.

    Now, with that said, I produce the final piece of the puzzle: advertisers generally pay by the click, not the view. If I don't click on an ad, it's irrelevent whether or not I viewed it. Therefore, if I screen out all ads that I wouldn't have clicked on anyway, no one gets hurt. I view ads that interest me, and click on them. I block ads that don't interest me, and don't click on them. I win, Slashdot wins, the advertiser wins.

    Simple as that.

    (To Whom It May Concern: Yes, I know my grammar is crappy. Who cares?)

  • You are dead on about pavlov. He is the major reason Mozilla is even close to usable on high end Linux boxes today. Based on Bugzilla logs and conversations, he was the guy who checked in all the enhancements that made real improvements in performance for Mozilla on Linux.

    Anyway, I haven't followed this stuff in ages really. I don't know about gcc and mozilla. Not enough of a guru to explain that one. :)

  • More to the point, why doesn't QT allow me to compile GTK apps against it, or vice versa?

    Because they are different libraries. This is like asking why you can't compile a C++ program against glibc or compile a C program with libstdc++.

    It looks like you are asking for someone to write a library that exports both the GTK APIs and the Qt APIs which would be a phenomenal amount of work.

    --
  • I hope you are kidding about compiling a C++ program against libc or a C program against libstdc++.

    You can call C functions from C++ and with a little work, you can call C++ functions from C.

    You seem to misunderstand what libraries are. The question isn't whether you can use C functions from a C++ program or vice versa but whether the library functions will exist.

    For instance if I compile the following C++ program against gcc which uses the C libraries
    #include <iostream>

    #include <string>

    int void main(void){
    int a=1, b =2;
    string c("+");
    cout <<a<<c<<b<<endl;
    }
    It will choke because it won't be able to find the code for a number of classes (string, ostream) and static objects (cout) because these are defined in the libstdc++ library and not glibc. It will compile fine[0] since the syntax is valid and the declarations can be found in the included header files but it will fail at link time since the needed classes and functions aren't in the libraries or source files the code is being compiled against.

    [0]If gcc wasn't also a c++ compiler then it wouldn't even compile.

    --
  • The question he poses to the community is: Maybe we should throw these two toolkits at a standards body to get the best of both worlds.

    I understand this and the latter half of my post addresses that.

    Currently there are a sizable number of apps written in both GTK and Qt meaning that in order not to break them, any new library meant as a replacement must support both APIs almost completely which is a rather large task and is potentially unweildy since both libraries probably have lots of functions that do the same thing and thus the new library will have to contain redundant operations and also be backwards compatible with any bad design decisions made in both libraries. Backwards compatibility is always a bad start just ask Microsoft, Intel and Bjarne Stroustrup.

    --
  • It is sad that there are so many people who seem to be programmers but can't tell the difference between syntax and libraries.

    From Bjarne Stroustrup's (creator of c++) book "The C++ Programming Language": "With minor exceptions, C++ is a superset of C. Well-written C programs tend to be C++ programs as well."

    Your argument only holds one way, that C++ programs cannot be compiled with libc. The only examples he gives of C code that's incompatible with C++ would lately be considered poor C.

    Ouch. You just revealed that you don't understand what is being debated. The question isn't whether C++ syntax and C syntax are similar enough to be interchangeable but whether the C library functions (e.g. strcpy, memcpy, mktime, etc) exist in libstdc++. If g++ simply uses both glibc and libstdc++ to compile programs so as to have access to both the C libraries and the C++ libraries then What is your point?

    And you should really listen to his advice:

    It seems you are more in need of the advice than I.

    --

  • Am I being trolled? (Score:3)

    by Carnage4Life ( 106069 ) on Tuesday April 17, 2001 @09:59PM (#283624) Homepage Journal
    Of course, you chose to only respond to one side of his rebuttal. You also said: "This is like asking why you can't compile a C++ program against glibc..."

    Which is exactly what I just showed.

    Anyway nitpicking whether a C++ program can use C functions overlooks the original point that libraries have to have the functions you want to use. Would you have preferred if I said "That is like trying to compile a Java program against libstdc++ or a C program against rt.jar?"

    You most certainly can call libc functions like 'printf' and 'fgets' from C++ programs

    Really. Is this because libc is also used by g++ when compiling C++ programs or that libstdc++ reimplements the functionality of libc. Either way your argument is pointless with regards to the original point that the library needs to have the functions you require.

    Write a library in C, and every single language under the sun can easily talk to it.

    Oops, now I realize I'm being trolled. You got me. IHBT. IHL. HAND

    --
  • Can someone explain to me the significance of this? I mean, Mozilla already runs under linux with Mozilla's own libraries. Why take a portable (albeit bloated) product and port it to a VERY limited set of APIs?

    Shayne

  • It will also choke because int void main(void) is not a valid way to declare the main procedure..

    Besides, you CAN call C procedures in C++ (very easily -- extern "C"), and you CAN call C++ objects methods in C (although not very easily thanks to name mangling). Yes, you have to link in the appropriate library, but you'd have a hell of a time getting a C++ program to link without bringing in the standard C library (libc). It's simply all a matter of resolving all external symbols. The linker doesn't really care if you're linking C, C++, Pascal, Fortran or any other language modules together, as long as the binaries are compatible, it'll do as it's told.

    However, this is getting WAY off-topic.

  • The Register [theregister.co.uk] ran a story about the effort to build some interoperability between Gnome and KDE today. Take a look at www.freedesktop.org [freedesktop.org]. Interoperability is an important issue to the KDE and Gnome people now (finally!). David Mason [redhat.com] at RedHat outlines what he and others decided should be important factors at GUADEC II, and I would encourage anyone who cares about either KDE or Gnome to support their efforts. Only by interoperability with they ensure that BOTH desktop environments have a fighting chance to survive.

    The list of immediate plans includes the simpler things to implement, including Menu/desktop files, MIME system, Themes (naming, pixmap engine), URI schemes, and Drag and Drop. There is a much larger list on the site, but those are the things to look for the next few releases of Gnome and KDE (there's already a draft stanard for the desktop entry system).

  • Some people are never happy. If you don't want an IRC client, uncheck the option box during installation. It's not hard to do.
  • Don't forget who is funding Mozilla. AOL have 29 million subscribers, all of whom may eventually be using Gecko in the AOL client.

    It's not as if AOL is inextricably dependent on IE since they've wisely ensured that their content and that of their partners is viewable with any browser.

  • Well you don't get AIM with Mozilla, but assuming you meant NS 6.0 then it is possible to remove it even if the installer doesn't give you the choice.

    Like the rest of the frontend in NS/Mozilla, the built-in AIM is just some chrome and a few DLLs. Edit the installed-chrome.txt file to remove references to aim.jar and NS will no longer contain AIM. Then you can delete AIM permenantly by removing aim.jar and the AIM component DLLs.

  • Moz interfaces (Score:3)

    by Mold ( 136317 ) on Tuesday April 17, 2001 @07:11PM (#283645)
    What's the real purpose in supporting ui ports (GTK+, Qt) if the Mozilla languages (XUL, etc) are supposed to replace those (to be more cross-platform friendly)?
  • much is the same way that Win32 provides a layer beneath MFC and VCL, which were once two very distinct toolkits.

    Perhaps we could write an "Xlib"... an X-tension library that would sit below Qt and Gtk.
  • You might find some of this information interesting.
    http://people.redhat.com/dcm/guadec.html

  • Re:Mozilla vs. Konq, development time... (Score:5)

    by update() ( 217397 ) on Wednesday April 18, 2001 @03:27AM (#283671) Homepage
    You can't really compare these two as projects, because they have completely different goals.

    Right, but it's still a legitimate question to ask which is a more sensible way to go about it. The reality is that the Konqueror team has come up with a pretty solid browser for Unix and embedded Qt with a tiny fraction of the resources and experience of the Mozilla project. Meanwhile, after all the labor invested in XUL/JS and the performance penalty it enforces on the browser, what do they have? The Mac version is pretty much despised for its poor performance and Mac integration (especially compared to Mac IE, which kicks ass) and the Unix version is dog-slow.

    If I were Steve Case, I'd be asking why they didn't just maintain Windows, Mac and Unix ports (keeping as much of the rendering engine cross-platform as possible) and make them each as good as possible. As it stands, they've pretty much conceded Windows and Mac market share to Microsoft, and now their monopoly on the Unix browser is crumbling.

    (Yes, I know, if I'd just try the latest nightlies, I'll see that everything has changed. ;-) )

    Unsettling MOTD at my ISP.

  • They are not the same. In fact, they are not even close. You might want to try something like wxWindows [wxwindows.org] or zoolib [sourceforge.net]. These toolkits "wrap" other toolkits for ease in portability.

    Beware that when you wrap like this, you generally lose the extra features of each toolkit in order to remain portable.

    Now I have to ask: why? Why would you want to do this? All this would do is change the look and feel of the application. This is not important. wxWindows and friends were made for crossplatform. Linux Qt -> Linux Gtk is not crossplatform, and isn't even worth talking about.

    Do you really want to use the widgets of the opposite toolkit that badly? Why not just use Qt? It is much more complete and proven than its competitors and has all you need.
    -Justin

  • Just a few thoughts on obvious reasons why you can't compare the two. I'm not going to try taking into account the project management dynamics of the two different groups (K vs. Mozilla) because as outsiders we can only speculate on things like bad management, morale, working conditions, etc.

    Konqueror:

    Is being developed by the same group that is working on a complete gui environment.

    Is being developed using an already established widget toolset.

    Is meant to run well first and foremost on Linux, and specifically KDE.

    Is being developed by a kompany that has a good history of working and completing individual application projects.

    Mozilla:

    Is the flagship product of the Mozilla group. It's even being built with the framework for other aps to derive from.

    Isn't working from an established widget toolset. They've been working within various environments including Windows, Linux, and Mac. It is very important that Mozilla works on all three of these platforms.

    Was started entirely from scratch. This in itself was important to the team.

    cough cough is associated with the same people who brought you Netscape cough cough

    The reason that Konqueror works so well within Qt-enabled X is the same reason that Explorer works so well within Windows. If soemone introduced you to some new gui environment and said "build me a perfect browser", it would probably take longer for you than for someone who'd already been working within that environment, let alone if you had to actually make your browser work over several gui environments. I can only imagine the hell that is trying to get something to render uniformly over several platforms. With Konqueror, that's QT's responsibilty and headache, not the Kompany's.

  • Looks like key features like plugin support and printing are still missing, so it's probably not the browser to use at the moment. Still, I run a KDE desktop, and it's nice to see Mozilla using my preferred toolkit. I'll wait for a while for it to settle down before switching to it (from konq and Gtk Mozilla), but props to the developers for getting this done!
  • Great, I need a qt base web browser more than I need a stable web browser. I went to the Mozzila parties, they where fun as well, but what I would really like is a working web browser. Don't integerate an email client and web browser, that is really dumb, now when my web browser crashes I lose that email I was about to send.

    Currently they aren't any web browsers that don't crash and can still browser 99% of web pages, I don't know why that is, but I don't a qt port is going to help this.

    I hope Mozzila can pull itself together, I'd really like to use a work web browser and an open source one at that.
    --

  • Banner Ad Invisibility (Score:3)

    by Cap'n Crax ( 313292 ) on Tuesday April 17, 2001 @07:22PM (#283699) Homepage
    A feature I think that would be cool in Mozilla would be a bit of code like:

    If ( ImageSize == 468 x 60 ) && ( KillAds == 1)
    Image = Transparent468x60

    Where the "KillAds" boolean is set in the preferences menu... Hell, maybe someone has already done this. I think I heard some talk that AOL would never allow such a feature to be included, but it would be easy enough to add in, I guess...

  • I see no reason why a particular tooklit or API should be more accessible to one language or another.

    In an ideal world, it would be like this. However, becuase this isn't an ideal world, a toolkit will almost always be more accessible in its native language (the one it was programmed in). You are, of course, free to chip in and change that with a new cross-language toolkit - I suggest you do it yourself if that's what you really want done. If you build it, they will come! That's what's great about Open Source and Free Software.

    Consistent look and feel =! theming! Please understand this! Its dialog boxes, widget behavior, panel application behaviour, drag and drop behaviour (xdnd still isn't used properly by either Konq or the GNOME desktop - try it with Konq FTP sometime).

    Ah, we're getting more OT. I thought you weren't talking about KDE/GNOME, only QT/GTK! Dialog boxes are provided mostly by the desktop environment. Panels and panel applications are provided completely by the environment, not the toolkit at all. (BTW, the KDE 2 panel supports WindowMaker dock applets - I think it can use GNOME panel applets as well). Widget behavior *is* part of themeing, with QT its possible to change the operation of a widget just with themes! Drag and drop interoperability is also provided by the desktop, and its improving - I suspect within the year it'll be working perfectly. The duplicate Control Centers and such are not a problem - just don't use the other one! And don't think nobody cares! That just shows that you don't read the KDE or GNOME mailing lists. Desktop Integration has been a big topic recently - there are joint mailing lists, community standards, and other stuff. The results are starting to show: the QT-GTK widget, XParts, more standardized DND (it used to be much worse), the gphoto KDE IOSlave. Its getting better all the time!

    Good point, but they're both unfortunately very rarely used.

    That's because they were just invented 2-3 months ago! Give them time, they will be used now that they are available.

    My understanding of the current QT licensing situation were that someone could port the Linux version of QT to Win32 to create a GPLed Win32 QT. Anyone care to correct me?

    Oh, sure. You'll *just* PORT it! Gee, why didn't I think of that?
    Seriously, though, if you think it's needed, start the project yourself. If it's really needed, others will help you. I think you'll have to get a lot of people to keep up with those guys at TrollTech, though. They aren't going to be standing still while you port QT/Linux to Windows.

    Um, yes. That's what I'm talking about.

    No its not. At least it wasn't. You seem to have switched gears now from "lets merge GTK and QT and keep compatibility" to "Lets create a whole new toolkit." Its a totally different argument now. Before you seemed to want to create a super-library that would be both backward and forward binary- and source-compatible with apps written in both C and C++ using different graphics toolkits! Now you want to start a new library that's better than all the rest. In that case, more power to you. Just don't expect source or binary compatibility with GTK and QT, and don't expect others to do it for you once they hear your great idea. If you want something done, do it yourself! Others may join you later, but they won't start it for you.

  • Really? Why does Mozilla even need QT then? Why doesn't someone just port it to XLib and be done with it?

  • One complaint down... (Score:3)

    by Spy Hunter ( 317220 ) on Tuesday April 17, 2001 @07:14PM (#283703) Journal
    A QT Mozilla port would automatically get AA fonts, just like any other QT program. Finally, AA Mozilla on X!

    Now if only they could address your other complaints...

  • Impossible. (Score:3)

    by Spy Hunter ( 317220 ) on Tuesday April 17, 2001 @07:38PM (#283704) Journal
    Sorry, your idea is neither practical nor worthwhile, because:

    • QT and GTK use different langages (C vs. C++ - yes that's too much of a difference to compensate for in any reasonable way).

    • If this came about, what would be the point of having 2 toolkits anyway? Why don't we all just switch to Win32 programming and use WINE? One toolkit is better than 2, right?

    • KDE can import your GTK+ and IceWM themes, making "lack of constant appearance" a matter of user choice.

    • What lack of consistency in UIs? Buttons, scrollbars, checkboxes, radio buttons, dockable toolbars - these concepts are almost identical in both toolkits. The only difference is in their appearence (KDE puts two buttons at the bottom of a scrollbar, but only in some themes, etc - this would be solved by QT importing GTK themes).

    • Making GTK compile QT apps (even though it's really impossible) would not help the stability, speed, or functionality of the Windows port of GTK, so it wouldn't help get a quality free toolkit for Windows any more than simply working more on GTK for Win32 directly.

    • Finally, the "limited widget availability between both toolkits" problem is about to go away. With QT-GTK and GTK-QT widgets almost ready and XParts in the works, programs for either toolkit can use widgets or components (think KParts/Bonobo) from both.

    Please bear in mind this is a completely different concept to merging KDE and GNOME, which have less to do with Qt and GTK than many people think.

    What? It has everything to do with QT and GTK! GNOME was started for the express purpose of providing a desktop environment based on something other than QT. If KDE and GNOME used the same toolkit, merging them would almost be a trivial task. Their choice of toolkits is the only thing really keeping them apart.

  • It's not clear that Troll Tech would permit the creation of an API-compatible implementation (but it's also not clear they have the legal power to prevent it). When people were developing Harmony, an independent implementation of the Qt APIs, Troll Tech apparently claimed it violated their copyright. This was never really worked out because Troll Tech changed their license to GPL, addressing the needs of KDE developers. Non-KDE developers didn't care enough and just went with Gtk+ (which is LGPL), and that's also what Sun and HP have adopted.

    In the end, it probably doesn't matter. I wouldn't expect either Gtk+ or Qt to be central to GUI development on Linux a few years from now. While mature, they represent a fairly tedious and traditional way of writing UIs. There are new paradigms already sneaking into real apps.

  • Mozilla vs. King Konq... perhaps we're taking this whole Japanese movie monster name thing a little too far...
  • MS consistently bashes their competition, and some people feel the need to respond. Go to microsoft.com and bask in the glow of marketing zealotry at it's finest (I love the bit about interoperability - it's a hilarious lie). Linux zealotry has died down a lot in the past 18 months. A duff ZDNet article provokes more laughter than fury nowadays.

Slashdot Top Deals

The explanation requiring the fewest assumptions is the most likely to be correct. -- William of Occam

Close