Re: Open to discussion...
- From: Nathan Clemons <nathan windsofstorm net>
- To: wm-spec-list gnome org
- Subject: Re: Open to discussion...
- Date: Sun, 20 Jun 1999 22:43:26 -0500 (EST)
On Sun, 20 Jun 1999, Derek Simkowiak wrote:
> > Duh, show me the documents that says it's part of the DE's responsibility to
> > handle icons. If the WM and the DE are fighting over icons we're doing
> > something wrong.
>
> The conflict comes between minimized window icons and file/folder
> icons. Basically, I was trying to say that a window manager should not
> have minimized window icons displayed on the desktop.
>
This is actually something that I like to see. Be it via the GNOME pager
or what, I want to see what applications are running, even if hiuden. THe
pager currently serves this purpose fine for me. But if not the pager,
then an icon would be very helpful. That was one thing about olvwm that I
did like.
Would there be some way, if the UI's will take responsibility of the root
window, to enable them to possibly communicate with an inconize request
and display the icon? Or should this evolve into a pager/secondary taskbar
function?
> > I can't follow you. Are you saying that users will usually have screwed
> > up configurations?
>
> Actually, yes, as it currently stands, they do. For example,
> install Gnome, then install AfterStep, and make note of all the features
> which are duplicated or are inconsistent in its user interface. The
> default configuration of most WMs conflict with the Gnome environment.
>
> Some people take the attitude that the user should simply
> configure their window manager to their liking. While I agree that should
> be possible, I disagree that an integrated environment should force
> non-Unix people (I'm thinking Mac users as the target audience here) to
> wade through page after page of documentation when they are used to
> everything being intuitive.
>
> There should be a default that is fully integrated, intuitive,
> and consistent with the Gnome desktop.
>
When someone moves from the default GNOME window manager to another,
they're making that choice. That can be for expirimental purposes, or that
could be because they are already familiar with the other window manager.
GNOME could also supply config parameters to the WM. Or, better yet, and
WM authors willing, it can be done via a config tool.
>
> > Of cource this can happen. But how do you think you
> > usually set backgrounds on a UNIX box? By calling xv/xloadimage/...
> > manually (i.e. by putting them in some script). Why is this a WM problem.
>
> I don't understand what you're getting at. Conflicting
> backgrounds, as was the case with the shipped version of Redhat 6.0, is a
> problem because it confuses the user to have two different places to
> change the background, especially when only one of the two places is
> accurated at any given time.
>
One other thing to mention here is themes. A lot of themes will also muck
around with the background image. User sets background image in the
control-center. They play around in the WM and change from theme a to
theme b. The background changes. They go back to the control-center and it
still thinks that it is displaying the old image, etc.
> > I don't see the problem. BTW, why do you think managing menus is part
> > of the DE? Even twm, the father of all window managers ;-) has menus.
>
> Click the big icon on the bottom left that has a foot on it, and
> you'll see why menus are a part of the DE.
>
Can be. That doesn't mean all menus should/must be solely the property of
the UI. In fact, in my opinion, they should not be solely done through the
UI.
> > Sorry, GNOME and KDE have one fundamental flaw if they want to be generic
> > interfaces like X: they take away the user's choice of a particular
> > look-and-feel.
>
> Correct me if I'm wrong, but I'm pretty sure neither Gnome nor KDE
> want to be generic interfaces like X. In fact, just the opposite: they
> are trying to provide consistent, intuitive user interfaces for Unix,
> something that X has lacked in its 15-year history (sans CDE).
>
Which has had it's good points and it's bad points. It allows immense
configurability and also immense frustration to people who don't want to
sit down through the learning curve.
>
> > A good DE shouldn't make assumptions of what things should look like
> > or how they should work but provide and interface for applications.
>
> It sounds like your definition of a DE and Gnome/KDE's definitions
> are quite different.
>
> [...]
> > I'm participating in this discussion to find the right way to do
> > things, not to make your life easy.
>
> *Ahem*
>
> > Oh, if users want a standard that is enforced upon them they can always
> > use Windoze. I get the impression that GNOME doesn't fit well into the
> > world of X applications (and it's nothing more than an application, you
> > should never forget this). This sounds awfully like the 'easiest approach'.
> > It's not that WMs have hijacked DE functionality, it's the other way
> > round. GNOME tries to do more things than it should (I don't know how
> > KDE does it, but I assume they do it in a mor WM friendly fashion since
> > they do have their own WM).
>
> At this point, I think your idea what a desktop environment is and
> what Gnome/KDE are trying to do is incompatibly different. Of course I do
> not speak for everyone working on Gnome, but I'm fairly certain that most
> Gnome developers consider Gnome something more that "an application".
>
>
Let me put this to the question then: what is the role of the DE or UI's
as I tend to refer to them? What are they trying to acheive, how do they
intend to go about doing it, what impact does this have on existing WM's
that choose to support them?
What things should the DE's NOT be handling?
--Nathan
-------------------------------------------------------------------------
Nathan P. Clemons "Peace favor your code."
nathan@windsofstorm.net ICQ: 2810688
IN CONSTRUCTION: http://gnome.windsofstorm.net
-------------------------------------------------------------------------
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]