[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Request for Packages in Fedora Core 3 -- "Pure" Qt "Killer Apps"



Lurker butting in here ...

Steven Pritchard wrote:  
> Personally, I think the major "problem" with Scribus is that it is a
> Qt app, not a KDE app, so it doesn't exactly integrate with any of the
> desktops available in FC.

Gareth Russell wrote:  
> I agree that it should be included but probably not as a default
> application due to its Qt status. It just doesn't integrate with the
> Gnome environment which is default in Fedora i.e. no Drag and drop
> functionality as in KDE. 

Peter Linnell wrote:  
> The reason why Scribus is not a purely KDE app is the desire to retain
> cross-platform compatibility. Scribus is available for fink, I am
> testing it with Cygwin and a native Win32 port is underway. We could
> not do this as a pure KDE application.

Peter, I 100% agree with the decision to go "Pure" Qt.

I consider two "Killer Apps" with _no_ Microsoft (although there are 3rd
party equivalents for Windows) equal to Linux to exist:  

1.  Typeset:  LyX ( http://www.lyx.org )

2.  DTP:  Scribus

LyX made the transition to a widget-independent codebase a couple of
years ago (it was XForms-based prior).  The result was not only a
preference for Qt, but an Aqua-native version for MacOS X (
http://www.18james.com/lyx_on_aqua.html )!  No X11 required (yes!).
Now there are still some licensing issues with the Windows version,
being that Qt/Win32 is not GPL.  But it's still an option that has
_no_ dependencies (other than TeTeX for the language back-end), because
it uses "Pure" Qt.

Using "Pure" Qt, Scribus also has the same option.  It can produce both
native Qt/UNIX and Qt/Mac versions that are fully GPL, as well as a
non-GPL Windows version using Qt/Win32 (non-GPL).

Now regarding DnD and GNOME integration, I can understand some
concerns.  But I have to believe there is nothing stopping Troll Tech
and other Qt developers from adding the small amount of code to support
DnD and other GNOME integration, at least for Qt/UNIX?  In fact, is
there such an effort underway or at least being suggested?

Just my thoughts.  I don't see any reason to "KDE'ize" Lyx-Qt or Scribus
at all.  There are many advantages to producing "Pure" Qt apps.

-- Bryan J. Smith, "Lurker" and anti-WP, pro-typeset/DTP advocate**

P.S.  Steve -- I'll respond to your further comment about "Extras" in
another post (i.e., I want to start another thread).

**BIAS EXPLAINED:  

I have _never_ been into "Word Processors" (WP) in general.  I consider
the WP to be a pre-GUI approach to documentation.

Pre-GUI, Pre-PC was the age of typeset.
Post-GUI is the age of Desktop Publishing (DTP).

In addition to the fact that DTP was invented on the Mac, even the
first, acclaimed documentation program on Windows was Ami Pro -- also a
DTP.  Although Ami Pro was somewhat simplistic, it was still more
powerful than MS Publisher today.

But, unfortunately, because of the proliferation of MS Word thanx to
Microsoft OEM bundling and rebates in the mid-'90s, most people have
never used either typeset or DTP.  If you're lucky, you might meet
someone who has used MS Publisher.  But because MS Publisher is an
elementary DTP, they dismiss it as "not powerful like MS Word."

MS Word attempts to be both a typeset and a DTP, and it is a bastard
that fails miserably at both.  That's because it lacks a good,
underlying documentation language.  Adobe FrameMaker, on the other hand,
does a fairly good job at both, because it does have an underlying
documentation language (even if not well documented).

There is no further proof in the capabilities of something like Adobe
FrameMaker v. MS Word than in Microsoft's own _preference_ for
FrameMaker for MS Office documentation.  Oh the irony!  [ I regualrly
use that argument, often in a losing fashion, when I am "forced" to
write 200+ page technical manuals at companies in MS Word -- Grrrrr! ]


-- 
Bryan J. Smith, E.I. -- b j smith ieee org




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]