Adam Skutt schrieb:
On Jan 18, 8:09 am, Arndt Roger Schneider <arndt.ro...@addcom.de>
wrote:
Back to rantingrick 21st century toolkit/framwork:
Let's have a look at the numbers:
Worlwide pc market are 300 Million pcs per year,
this number includes desktops(2/3) and servers(1/3).
Your gui app is not relevant on servers.
You should tell this "fact" to just about every major enterprise
software manufacturer out there. They all ship GUI tools intended to
be used on the server. Some of them ship only GUI tools or CLI tools
that are worthless, making you use the GUI tools.
The desktop pc market is in decline; there is
however a shift toward pc-servers, instead.
It is anybodies guess how far the pc-desktop decline will go.
Every 21st century toolkit or framework must run on
mobile platforms!
Until we have pixel-perfect touch sensors, toolkits for devices with
pointer interfaces (e.g., PCs) and toolkits for devices with touch
interfaces (e.g., phones and tablets) will necessarily be different.
You note this yourself: the UI paradigms that work well when you have
a pixel-perfect pointer do not work at all when you have a touch
screen, especially on a limited size and resolution display.
Yes I did and that's how it is.
Even if you're provided a "single" toolkit, you still end up with two,
maybe three, different applications, each using different widgets
targeted for the device they run on. And no one provides a "single"
toolkit: while Silverlight can run on the desktop, the web, and now on
Windows Phone, you can't use the same widgets everywhere; ditto with
Cocoa for OS X and Cocoa Touch for iTouch devices.
While some further unification is obviously possible, it's rather
doubtful we'll ever have unified widgets that are truly workable on
the web, on the "desktop", and on a portable touch screen device.
Think about all the programmers earning their butter and bread :-).
Forget toolkits and widgets for awhile.
What remains are specific types of human/computer interactions,
a visual representation on a screen and a predefined behaviour
for said human action.
E.g. a button is:
A function gets asychnronously performed in response to
a finger/mouse click and release inside a certain screen area.
--A widget is essentially a logical abstraction.
wxWidgets was written ~1992, it is a copy of
mfc, which in turn is a copy of MacApp. MacApp
is also OSS, maintained through an industrie consortium.
Why do you not use the original framework?
Because it's not cross-platform, I'd imagine. The entire point of
wxWidgets was to provide a cross-platform "OOP" UI toolkit. It
closely copies MFC since MFC and XView were the two "backends" it
supported.
MacApp is/was cross-platform, Apple pulled the plug
on the non-mac platforms; the industrie
consortium took charge of the other platforms.
Screen resolution:
The time of 72ppi CRT monitors is over. A GUI
framework/toolkit must be resolution independent,
including all icons and indicators;
it should use decluttering (newspeak:ZUI).
WPF is the only functional resolution-independent UI toolkit in
existence. While I don't disagree with you in principal, practice is
pretty heavily divorced from principal here. Principal doesn't help
me write GUI applications today.
wxWidgets is not suitable for a modern type
GUI ad thus clearly not the toolkit/framework
of the 21st century.
None of the toolkits accessible from CPython are suitable for a 21st
century guy by your standard. If we talk about IronPython,
Silverlight becomes the closest, but it isn't a panacea by any stretch
of the imagination.
Adam
According to Microsoft neither is silverlight.
-roger
--
http://mail.python.org/mailman/listinfo/python-list
