Konqueror Compiled For Mac OS X; KOffice Next

scishop writes "Benjamin Reed has just compiled Konqueror for Mac OS X after porting the KUniqueApplication class. A screenshot of the running program can be found here. According to Reed's blog, 'next up is KOffice.'"

Re:seems odd...

[Anonymous Coward]

while I agree that it is odd, there were a good number of other browsers for OSX

MSIE, Netscape/Mozilla, Safari, Camino, etc.

Re:seems odd...

[after]

What a great idea!

That IS odd that they could not have ported
that to the Cygwin platform... I mean, X11
is available and all.

Wait, but isnt there already a port of KDE [sourceforge.net]
to Cygwin?

Re:seems odd...

[Durin_Deathless]

This port doesn't use X11 at all. I have been on the maillist, and the stumbling block has been the X11 specific code(and a minor thing in QT-mac, reguarding extensions of shared libs). This is a real achievement, and rangerrick is to be greatly congratulated!

A bit offtopic, but I need to vent

[Starship Trooper]

Perhaps someone on the Qt/Mac or equivalent GTK project could answer this for me. Why is it that when these toolkits get ported to another other platform, be it Windows, MacOS, BeOS or what have you, they insist on looking and acting as GTK or Qt applications rather than native apps? A Qt/Windows or GTK/Windows app would be much more useful and usable to me if it used native Windows widgets and thus fit in with every other program I use.

As an example, I use gaim on FreeBSD because its tabbed interface is simply the best I've come across. I would love to use it instead of Trillian when I'm forced into using Windows. But the Windows port of gaim, which uses GTK+/Windows, works horribly. The GTK theme doesn't match my XP settings, widgets draw slowly and work clumsily (tooltips in particular seem to spontaneously appear and refuse to go away, even when the program is minimized!), and all in all it feels like a cheap Wal-Mart knockoff.

GTK+ widgets offer no benefits over standard Windows controls -- they draw slower, they don't match the environment, and Windows is just as themable as GTK is. Going back on-topic, this Qt/Mac port of Konqueror likewise eschews native widgets for the entirely out-of-place Qt look. All I can ask is Why? Wouldn't it be far easier for Qt/ and GTK/Windows or /Mac to simply wrap native widgets, rather than poorly ape them?

Re:why?

[abigor]

Can other browsers drag a file from a remote machine via ssh and drop it on another machine via ftp? Browse a digital camera? Connect to SMB shares? And of course, browse the Web - all at the same time, in different tabs and split screens?

No. Konqueror browses practically everything, not just the Web.

All that said, I do wonder if the kioslaves made it into this OS X version of Konqueror.

Re:Why isn't X11 running?

[clarkcox3]

Yes, that's the whole point of what he did. You can already run KDE under X11 on OSX. (I've done it before). The thing that is special about this was that he actually *ported* it to OSX's Quartz windowing system.

Re:Redundancy

[clarkcox3]

You're not misinformed, Safari does indeed use the KHTML engine. But the point of this appears to be to show the world that KDE apps can be ported to OSX in a manner that they won't require X11 (which a lot of the less-expert users shy away from). This means that these applications can be "first class" Mac applications.

I.e. someday soon, we may see grandmas everywhere running KOffice instead of shelling out hundreds for MS Office.

Re:The question is..

[keating_5]

Konqueror is more than a web-browser. Its other major use is as a file manager, among other things.

Re:OT, but what about Evolution?

[Binary Boy]

Evolution runs fine under Apple's X11, though a native port would be nice... it's a fine IMAP client in its own right, regardless of the Exchange features.

The big problem is getting those Exchange features - those are only available via the Exchange Connector for Evolution, which is a commercial product and is not available for OSX using X11. If there was a native port of Evolution then we'd still need a supported version of Connector, and would still have to pay for it.

Re:A bit offtopic, but I need to vent

[jdub!]

Check out GTK-Wimp: http://gtk-wimp.sourceforge.net/ Very tasty, if you run GTK+ applications under Windows (particularly XP). It's even mentioned on the Gaim website. :-)

Re:why help a megacorporation like apple?

[libra-dragon]

For the same reason that Apple paid people to make contributions to the KHTML project.

Re:OS X Maximizes browser choice?

[Graff]

omniweb is safari in drag. and konqueror, although nice it is finally ported, is more or less for proof of concept. opera for mac isn't even up to 7.0 yet if i remember right, with opera being all pissed at apple releasing safari. so that really leaves you with safari, and the mozilla browsers.

OmniWeb may use the same underlying rendering and scripting engine that Safari uses but it is actually quite different than Safari. They are both great products but OmniWeb by far provides you with more functionality

About the only thing that Safari has over OmniWeb is tabbed browsing. OmniWeb has many more options than Safari such as regex filtering of content from sites, the ability to easily masquerade as any type of browser running on any type of operating system, autofilling of forms, tons of display options, the ability to set up shortcuts for the url input line ("google something" starts a Google search for something, "dict something" looks up something in dictionary.com, etc), and much more.

I'm not knocking Safari, it's a really nice, lean browser but its feature set is almost too lean. OmniWeb is kind of like a full-featured version of Safari.

No goatse links, Crypto Gnome=troll

[el_munkie]

OS X screengrabs are natively in PDF format. I didn't feel like Photoshopping the PDFs into JPEGS, and since it's hosted on my webserver, I don't particularly care how wasteful it is of bandwidth. Plus, I want to see how my Linux machine holds up against a small Slashdotting.

If you don't like it, fuck off.

Re:A bit offtopic, but I need to vent

[Jamie Zawinski]

it comes with the territory since X never came with a standard widget set.

Not true: X came with a standard widget framework, X Toolkit Intrinsics (Xt) on top of which the first two X widget sets were built (Athena and Motif.)

GTK and KDE both chose to ignore the existence of Xt.

One of the (several) unfortunate side-effects of this decision is that it's not possible to mix and match (for example) Motif and GTK widgets in the same application (or GTK and KDE widgets, for that matter.) Whereas, it was possible to mix Athena and Motif widgets together.

Re:OS X Maximizes browser choice?

[Eridius]

Safari has browser masquerading (enable the Debug menu), autofill, and such. There's no shortcuts, but I *believe* there's a third-party plugin that adds it (I'm not sure). There's no regex filtering, but PithHelmet is a third-party plugin that adds it.

Re:Unicode?

[netsharc]

Take a look at this [befunk.com]...

There are a few more screenshots, just go to the parent directory.. I hope it doesn't kill his server. :)

Re:Biting the fodder with KOffice

[manly_15]

For a GPL'ed SFTP/FTP program try out Cyberduck [unizh.ch]. It rocks :)

Re:Oh yeah...

[funkhauser]

"This should have precisely zero advantages over Safari . . . I only use KDE on Linux for the desktop and file manager . . ."

You said it yourself. Konqueror is more than just a web browser, it's also a file manager, with a lot of very nice features. While the port is primarily more of a proof of concept than anything, it does have advantages over Safari.

Re:IM clients

[PinkX]

Kopete [kde.org] is one of them, and AFAIK it is (or will be?) the official KDE IM client. It supports multiple protocols and is based on a plugin system.

And just in case you're wondering for its name, Copete is like we call here in Chile to the alcoholic beverages (like booze), and the main Kopete developer and author is chilean.

Regards!

Re:MHTML

[00lmz]

A .war file is just an ordinary gzipped tar file with all the relevant files (graphics and style sheets) in it.

Re:safari == konquerer port ?

[PinkX]

You are a little bit confused over this one. KHTML is the Konqueror/Safari html rendering engine, like what Gecko is to Mozilla/Galeon/Firebird.

Re:The question is..

[rendler]

- it was designed from the ground up and is conceptually sound, unlike mozilla which was a hack job on top of netscape's browser

The old Netscape code was dropped and Mozilla started it's life from stratch.

- unlike other browsers (mozilla, IE), it was designed using 'mature' technology (HTML4, CSS, etc.) and does not have nearly as many compatibility woes as IE, nor as many add-on hacks, as the other browsers had, due to changing stnadards over the years (in other words: it's a newer, fresher code base)

Mozilla is the most standards compliant browser in the world par none. It also has better CSS1/2 support than any other browser, including Konqueror.

- unlike mozilla/firebird, I can use it for hours/days with many pages open (15+) without the entire affair slowing to a crawl and/or dying

How the hell are you using it when other people including myself have had more windows open and had it running longer (into weeks) without having to restart it.

Re:Biting the fodder with KOffice

[hysterion]

Fugu [umich.edu] is nice for SFTP, too. BSD'ed ;)

Re:A bit offtopic, but I need to vent

[firewrought]

Why is it that when these toolkits get ported to another other platform, be it Windows, MacOS, BeOS or what have you, they insist on looking and acting as GTK or Qt applications rather than native apps?

A few months ago, I did a lot of searching for a cross-platform GUI toolkit. Some toolkits try to use native widgets (a la Java's AWT), but most implement their own drawing, optionally with themeability (a la Java's Swing). Why this bias against native widgets? I'm going to take some wild guesses: (1) many of these cross-platform GUI toolkits were not intended to be cross-platform, but they got popular and somebody wanted a quick and dirty port of their application to windows... instead of reengineering the toolkit, it was easier to port it. (2) it's more appealing to build something new than to merely wrap existing toolkits... not always a good excuse, but commonly used, I would guess. (3) wrapping native widgets threatens to be a maintenance nightmare... if you were wrapping just one native GUI, it would be straightforward, but if you want to support several, it's going to be a painful mash of code that is constantly breaking due the intricate coupling b/t the toolkit and native code. Adding new platforms would take considerable effort. (4) It's much easier just to reduce coupling to a minimum by doing the barest amount of buffer swapping and event handling with the native windowing system... and this means drawing your own widgets. Also, (5) you sometimes might want to introduce architectural innovations that don't translate to the native API's well. (6) Finally, the toolkit can only properly support features which are in the intersection of all the native API's it supports... features that are not implemented by all native API's can be implemented by the toolkit, but then the toolkit must try to handle that case specially (or worse, the programmer has to know the ins and outs of how the toolkit behaves on different platforms).

In a word, I think many programmers are content to screw the users (or put the burden on the UI artists who have to make themable toolkits look like the real thing). It's not user-friendly, but it is expedient.

The solution is not to make better toolkits (dang we have enough of those already)... the solution is to decouple the UI from the application logic where possible. Standard file formats and network protocals, proper seperation logic into shared library components, proper use of remoting technology (CORBA, RPC, web services, etc.) all work to make this possible. Case in point: I run an imap server on my network and store all of my mail on it. I can access it via a web interface (squirrelmail), a GUI interface (kmail, mozilla, perhaps even Outlook), and a curses interface (mutt)... whichever happens to most convienient and closest at hand. This is not a solution for every problem, but it should work for your example (an IM application).

Re:Now...

[rixstep]

doesn't seem as fast as IE to load or as responsive on low-end hardware

The 'low-end hardware' bit I can understand, but traditionally, IE has cheated in two respects:

1. It plays dirty tricks, tries to foul up Netscape/Moz starts, and the Moz code has to go hunting in the Registry for all the booby traps and remove them first.

2. Windows loads most of the IE engine on startup. MS used to have a 'Preload' key in the Registry which could be turned off. If you turned it off, IE was slow as molasses to start. MS have removed the key now, and what I've heard, on XP Moz loads about as fast as IE. But that's only what I've heard.

Re:why?

[Reblet]

I don't think the important achievement is in the fact that the we now have another browser on Mac OS X, because there is enough choice out there, nor is the additional feauture set of Konqueror important to me.

What IS important is that some people have figured out how to isolate KDE from X11, which sets a precedent for porting other KDE apps to Mac OS X. Programs such as KOffice or Kopete do seems worth the bother to me.

Reblet

Re:A bit offtopic, but I need to vent

[be-fan]

The Qt/Mac port looks almost identical to Aqua, except for when Apple changes major things (like the tabs in 10.3) and TrollTech needs to catch up. The Qt/Windows port look native as well.

Re:To Answer all the "Why Bother?" Posts...

[jbolden]

Which had a modern file system first? Hint: in no case was it MacOS.

I think it depends what you mean by "modern". When Unix was created it used a very simple file system compared to most operating systems of the time because of the "everything is a stream of ascii text" metaphore. That is to get piping to work the database file systems which were common at the time were not used. "modern" file systems seem to be returning to the 70s filesystems and even on Unixes most applications don't create streams of ascii. MacOS had metadata which is more in the "modern" direction than windows.

OSS != Linux

[TheRaven64]

So when will apple port something to Linux? The iapps will be a good start. :rollseye:

Apple does give back to the OSS community. They contribute to the GNU project (gcc), to KDE (KHTML upgrades for WebKit have been ported back) and they even provide kernel-level things (the HFS+ filesystem driver for FreeBSD comes from Darwin). Why should they give anything to Linux? Linux is just a kernel, and has contributed nothing to Apple...

Re:Woot!

[LittleLebowskiUrbanA]

Bullshit. Finder crashes daily on me browsing my Samba network under 10.3 which is fully updates.
Did you think I made this up? There's a thread going on about Macs over at OSnews and many people are having the same problem I have. Just because you haven't experienced it doesn't mean it doesn't happen.