[Desktop_architects] Portland: The Linux Desktop IntegrationInterface

[Steve Northover]

What?

While there are many possible widget toolkits that execute on a given 
platform, by definition, the native widgets for the platform come from the 
operating system vendor.  The operating system vendors define the look and 
feel of their widgets and the look and feel of the platform.  Key 
services, such as internationalization, drag and drop (data transfer), 
input methods and desktop services (registry etc.) make use of these 
widgets and the concepts surrounding them.  For example, Windows expects 
you to use OLE (ActiveX), HWND's and ImageLists when programming drag and 
drop.  If you don't, you can't drag and drop to other applications on the 
desktop and your drag and drop will most likely look strange (ie. it might 
have the wrong cursor when you hold down the control key).

I'm sorry if you guys can't see this (or don't want to) but it is at the 
heart of many of the problems you face.  For example, off the top of my 
head, when I provide an icon for my program on the desktop or in the 
system tray using the new Portland API, what will the data type be?  In 
theory, it can't even be an X image because some of you run on frame 
buffers.

Here is a list of the platform and the corresponding native widgets:

Mac
- Carbon (the old C based widgets)
- Cocao (the new Objective C based widgets)

Windows 98, NT, 2000, XP
- Win32 (all other technologies from Microsoft are built on top of this)

Windows Vista
- Win32 (the old C based widgets)
- Avalon (new .NET/CLR based widgets)

Unix (AIX, HP, Solaris)
- Motif
- GTK (Solaris only)

Linux
- GTK+
- Qt
- Fox
- Motif
- ... others?

QNX
- Photon

Steve




George Staikos <staikos at kde.org> 
Sent by: desktop_architects-bounces at lists.osdl.org
12/05/2005 11:09 AM

To
desktop_architects at lists.osdl.org
cc

Subject
Re: [Desktop_architects] Portland: The Linux Desktop IntegrationInterface






On Monday 05 December 2005 01:01, Brooks, Phil wrote:
> As an attendee at the ISV session, the ISV issue of two widget 
development
> environments was certainly a point of contention between the ISVs (there
> should be 1 widget set like on Windows and Mac) vs. reps from the two
> desktops (there isn't any way to do that).

   Again, I have to point out that it's completely untrue that there is 
only 
one widget set on Mac OS or Windows.  I said it so many times at the 
meeting, 
and clearly I have to restate it -again-!  There are many:

Mac:
- Carbon
- Cocoa
- Java
- Qt
- wxWidgets

Win:
- Win32
- MFC
- .NET and associated things
- Qt
- Delphi
- wxWidgets

And:
- GTK+ on some of those I think

  Most of those adjust their look and feel to the platform they're running 
on, 
or extend existing widgets on that platform.  Some are shipped with the 
platform, some are extra downloads, some are ISV products.  Note that on 
Linux, all the widget sets use the same underlying implementation: X11.

  Do ISVs complain to Microsoft that they have even more choice than they 
do 
on Linux right now?

  What you're doing here is defining an answer to an unspecified question, 

then complaining that this answer isn't a reality.  The question is most 
important, and we will solve it appropriately.

  I think it goes something along the lines of: "What is the interface for 

Linux applications to interface with desktop functionality and services, 
independent of what environment is running?"  The answer to that, is there 
is 
none yet.  One of the primary goals and outcomes of the meeting we had was 
to 
define and develop one.

> I wonder in retrospect if the ISV issue would be more accurately voiced 
as
> there being two second class widget sets.  I mean not that the widget 
sets
> themselves are in any way flawed, but there is the distinct flavor of 
the
> development libraries being firmly attached to one or the other desktop 
and
> being in some way second class on the other desktop.
>
> I wonder if it would be possible, from both a marketing viewpoint, and a
> technical viewpoint, to remove the widget set preference for the 
desktops
> as far as hosted ISV applications are concerned.  That way, an ISV could
> choose between the widget sets on their own technical merits, and
> (eventually) not worry about that widget set providing a better user
> experience for one desktop and not fitting in well with the other.
>
> What would that take?

   It would require a complete rewrite of both desktops, which is for sure 
not 
going to happen for a multitude of reasons.  Technically what you ask for 
is 
already there, it's just that it's not the answer that you, or anyone, 
want 
to hear.  It's plain Xlib, and that's just not useful. :-)
 
-- 
George Staikos
KDE Developer                                                            
http://www.kde.org/
Staikos Computing Services Inc.                          
http://www.staikos.net/
_______________________________________________
Desktop_architects mailing list
Desktop_architects at lists.osdl.org
https://lists.osdl.org/mailman/listinfo/desktop_architects

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/desktop_architects/attachments/20051205/f831847a/attachment-0001.htm