discuss-gnustep
[Top][All Lists]
Advanced

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

Re: pure gnustep system


From: Jamie Ramone
Subject: Re: pure gnustep system
Date: Sat, 31 Mar 2012 19:25:14 -0300

On Sat, Mar 31, 2012 at 12:26 PM, Ivan Vučica <address@hidden> wrote:
>
>
> On Sat, Mar 31, 2012 at 09:55, Jamie Ramone <address@hidden> wrote:
>>
>>
>> OK...why? Where its it said that you need these things for it to be
>> good? I find all the current wizz-bang decorations and effects
>> annoying and distracting. While I'm sure there are people who like
>> them I'm not convinced that most people do. Also the only OpenGL UI
>> I've actually seen on X is the one on MeeGo...the Windows Millenium of
>> GNU distributions.
>
>
> Compiz has many annoying features. So are some things in OS X Lion. Windows
> Vista/7 "require" the use of the compositor only to paint the most useless
> task switcher I have seen.
> However.
>
> Entirety of the user experience consists of many small improvements. I like
> Snow Leopard's Spaces. I like the general idea of Expose. I like the custom
> addon for OS X adding preview of application's windows when you roll the
> mouse over the dock. These are some of the useful things that work well only
> with a good, GL-accelerated compositor, and while not absolutely necessary,
> they can be properly executed and they can be very useful. It's disputable
> whether or not one actually wants too many animations - for example, I find
> OS X Lion has crossed the line, and Compiz is also capable of becoming an
> animated monstrosity. But animations are not the most important part of the
> idea of permitting GL-accelerated compositing. It's simplifying task
> switching and data access.

The key work being "improvements". You don't necessarily NEED them
either, they appear as result of want as well as need. Just because
they are GL-accelerated (the most oxymoronic term if there ever was
one), doesn't mean they have to be. They just need the compositor to
do it's job right.

> I really don't care about the basics and about basic animations. They can be
> tasteful or distasteful. But you may be limiting the features environment
> could one day be capable of. One of disputably-useful Lion's features comes
> to mind: autosave-in-place (you know, the per-document time machine). While
> the principle behind it -- saving is automatic, manual saving is
> checkpointing -- is confusing to users, and potentially slows down the app
> and system, versioning is not. And it's very useful to be able to browse
> previous versions of a document side-by-side, along with being able to
> interact with that version of the document in order to copypaste from it, or
> what-not.

Just because some feature is not in the first release of the interface
doesn't mean it would be impossible to add it later. For now I'll
concentrate on the GUI actually having functionality. All the
glitziness can be dealt with later.

> User interface of this old-version-browser is somewhat annoying and
> eyecandyish, but the basic principle behind it (there's a stack of windows
> aligned in a timeline) is not. I wouldn't put old versions one on top of
> another, and would rather put them horizontally next to each other, but
> that's a design decision. You still wouldn't be able to easily do this using
> anything but a compositor.

The windowing server IS a compositor. That's one of it's primary functions.

>
>>
>> That being said, the UI will be initially based on the OPENSTEP 4.2
>> interface and grow from there. I do have plans for much later to
>> re-work it into the first REAL 3D GUI. I say first 'cause I've heard
>> many claim this but either fall short or is an outright lie.
>
> I saw some "real" 3D GUIs. None of them were compelling.

So have I...and I wholeheartedly agree.

> I'd love to see one that truly makes use of 3D and that's easy and fast to
> use. Anything that's AppKit based can never be "real" 3D and that's a good
> thing; it can make use of 3D acceleration, it could perhaps paint buttons as
> boxes or something like that, but I doubt that's what you meant. :-)

Quite right, I was talking about the workspace, not the toolkit ;-)

>>
>> Actually, the backend would generate PDF code and send it to the
>> sever, which would draw it on the screen through a display-driver
>> module. This module is a plug-in implemented as a bundle and can be
>> anything. The one I'm writing uses SDL to interact with the display,
>> but others can be developed. And things like OpenGL don't have to be
>> IN the server, or be used by it to draw on the screen
>
> This sounds interesting, and I can't wait to see it.
>
> I didn't dig deep into either of the techs, but isn't something similar the
> idea behind Display Postscript, as well as gnustep-gui+gnustep-back?

You don't miss a thing, do you? ;-) Yes, that's exactly what it is.
The original design was right. And moving from PostSctipt to PDF is a
logical evolutionary step.

>>
>> As for it being great or not, it's really just a matter of taste. You
>> might not like it for one reason or another, someone else might be
>> like "meh, I've had better", while others might be all like "OMG I
>> can't believe I've been able to function in society without this!!
>> What a total eye-gasm! EVERY THING ELSE IS SO GHEY!!"...and everything
>> in between.
>
> I completely agree. I just believe that compositing, as well as animating
> parts of the UI, is not purely eyecandy.
>

I disagree, those things aren't a necessity. They can be useful, but I
see no reason they should be integrated inseparably into the system.
They can be part of GNUstepGUI, or as a separate lib for just some
applications.

>>
>> To me it's not the Well Known Features (TM) that are important, it's
>> the overall architecture. As the contractor said in The Money Pit "But
>> the foundation is good. And if that's OK, then everything else can be
>> fixed". The branded standards and technologies (to us the term
>> loosely) are just fads that come and go...remember VRML or Gofer?
>> Anyone? Things like OpenGL didn't exist forever. It's here today but
>> could be replaced by something else tomorrow, so I've learned to
>> ignore these things and go with my gut.
>
> That's a good way to go, as long as you don't completely discard the
> technologies you can use today.
>
> I'm pretty sure OpenGL isn't going anywhere for the next 5-10 years,
> considering the vast amount of software written for it -- especially in the
> last 4 years for mobile platforms.

Yet there's no guarantee of that. I've seen one of these OpenGL
UIs...MeeGo. And I was thoroughly NOT impressed with it.

> Thanks for the great discussion!
>
> I'm wondering, however, are you intentionally replying just to me instead of
> the list? If so, I apologize for CCing the list.

Goddamn GMail reply button, I wanted to repy to the list, not the
first address in it! Thanks for CCing, fortunately this time I went
and used the "Reply to all" button, which should be the first choice
if there are addresses in the CC field of the original mail. You'd
think the guys at Google would've figured that out by now.

> --
> Ivan Vučica address@hidden
>

-- 
Besos, abrazos, confeti y aplausos.
Jamie Ramone
"El Vikingo"



reply via email to

[Prev in Thread] Current Thread [Next in Thread]