|
|
Subscribe / Log in / New account

Screenshots

Screenshots

Posted Mar 8, 2010 20:07 UTC (Mon) by epa (subscriber, #39769)
Parent article: Try the Linux desktop of the future (TuxRadar)

I think screenshots for reviews or articles like this should be made with a plain desktop background, not a distracting image of pebbles or blue shiny squares or even rotated Plasmoids. The old Unix tradition of screenshotting the application window itself with none of the window manager decoration may be a bit too purist, but I think we need to distinguish the important details of the program being reviewed from ephemeral stuff like what shade of browny-purple your distribution is using this month.


to post comments

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 1:38 UTC (Tue) by BrucePerens (guest, #2510) [Link] (31 responses)

Don't these new desktops appear to be significantly influenced by Macintosh? Now, I'm sure there's a lot that's innovative (and you're welcome to tell us) but it would be nice if at first glance they didn't look derivative.

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 1:48 UTC (Tue) by jebba (guest, #4439) [Link] (21 responses)

I just took gnome-shell for a test drive (on Fedora 12) and it didn't feel like a Mac at all.

I also went to download gnome-do, but saw that it was Mono based, and held back. I prefer my simple openbox setup, but I'm sure the new desktops will have their fans.

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 1:53 UTC (Tue) by BrucePerens (guest, #2510) [Link] (3 responses)

It's mono-based. That's not derivative at all :-)

You aren't going to catch me running that, either.

Timely?

Posted Mar 9, 2010 2:00 UTC (Tue) by dmarti (subscriber, #11625) [Link]

I like the way this story ran soon after the "Apple sues UI imitators" and "Mono sponsor to be broken up by corporate raiders" stories from last week.

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 10:12 UTC (Tue) by sylware (guest, #35259) [Link]

Mono? ERK!

I won't run that bloat, my browser is already too much.

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 18:09 UTC (Tue) by bronson (subscriber, #4806) [Link]

Gnome Shell is Clutter+Javascript, and Clutter is written in C. *whew*. You had me worried. If Gnome Shell were written in Mono, I'd have switched to KDE today.

Yes, Gnome Do is mono-based. In fact, it's a perfect Mono poster child: bloated, overhyped, and underwhelming. A little buggy too. I tried it for a few weeks, filed some bugs, then uninstalled it with relief.

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 10:41 UTC (Tue) by drag (guest, #31333) [Link] (3 responses)

> I also went to download gnome-do, but saw that it was Mono based, and held back.

Yah. I felt the same about KDE. Mircosoft uses C++ in almost everything they make so I am
worried about the patents.

(joke)

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 17:27 UTC (Tue) by bronson (subscriber, #4806) [Link] (2 responses)

Did Microsoft invent C++?

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 19:45 UTC (Tue) by jzbiciak (guest, #5246) [Link]

No, that happened at AT&T, the company that got everyone saying "*nix" instead of Unix. ;-)

Sigh. Don't they look mac-like?

Posted Mar 12, 2010 11:19 UTC (Fri) by epa (subscriber, #39769) [Link]

Microsoft is heavily involved in the C++ standardization process. The convener of the ISO committee on C++ is Herb Sutter, who works for Microsoft.

just say moNO

Posted Mar 9, 2010 10:43 UTC (Tue) by linuxjacques (subscriber, #45768) [Link] (10 responses)

me too.

I don't understand the mono push.

just say moNO

Posted Mar 9, 2010 13:37 UTC (Tue) by Trelane (subscriber, #56877) [Link] (9 responses)

Because most gnome devs have used the c bindings which can be rather a pain at times (mostly boilerplate or other work that the compiler takes care of for you in other languages) plus a real hate for c++ and java. (IMHO, the GNOME c++ bindings are awesome).

just say moNO

Posted Mar 9, 2010 13:50 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

A number of GNOME applications are written in C++, Python, Vala and other
languages and the community have always been open to that. Some folks use
Mono especially from Novell.

just say moNO

Posted Mar 9, 2010 14:51 UTC (Tue) by Trelane (subscriber, #56877) [Link] (2 responses)

"A number" yes. Not an extremely large number, as far as I can tell. But lack of non-C binding experience is what I've seen driving this. (I can't find any links immediately that support this; this is just my impression after reading planet gnome and listening to them on #gnome-hackers.

just say moNO

Posted Mar 9, 2010 14:52 UTC (Tue) by Trelane (subscriber, #56877) [Link] (1 responses)

Well, perhaps python is pretty widespread in retrospect. Vala is not very widely used atm. C++ is used more, but not a whole lot more as far as I can tell. Python is dynamically-typed, tho, and semi-scripting so it's not precisely the same.

just say moNO

Posted Mar 9, 2010 15:00 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Python is extremely popular (http://www.pygtk.org/applications.html) and C++
has a few important apps (Abiword and Inkscape for example) as well Vala is
fairly new and considering that a considerable number of apps have already
been written and I use some of them on a regular basis including shotwell
and deja-dup.

just say moNO

Posted Mar 10, 2010 2:32 UTC (Wed) by lwkejrlej (guest, #64237) [Link] (1 responses)

> plus a real hate for c++ and java.

Is this really the case ? It would be a shame, as replicating C++ features in C is a real pain (GObject is a mess when compared to C++ classes). Why reinvent the wheel ?

just say moNO

Posted Mar 10, 2010 7:31 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I don't think it is true and atleast I don't see any basis for that claim
whatsoever. I am not sure why you consider GObject to be an issue and it
would be interesting to hear more analysis on that. Toolkits tend to use
their own dialects and extensions anyway (Qt's moc and signal/slot
mechanism..)

just say moNO

Posted Mar 10, 2010 11:40 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses)

I believe that many of the original Mono developers at Ximian / Novell had worked on the Evolution mail client, which is a GNOME application written in C++ (and is not exactly famous for being rock-solid and lightweight). Mono was partly an attempt to make an easier way to develop applications than using C or C++. So yes, you may be right that it was motivated by 'hate for C++'.

just say moNO

Posted Mar 10, 2010 16:44 UTC (Wed) by sbishop (guest, #33061) [Link] (1 responses)

I don't see any C++ Evolution code, though I am no Evolution hacker and may just not have looked in the right places.

just say moNO

Posted Mar 12, 2010 11:16 UTC (Fri) by epa (subscriber, #39769) [Link]

I stand corrected. From the early Changelog entries it's clear that most development was done at Helix Code (later Ximian, now Novell). But it remains an open question whether using C++ might have made development easier, without needing the bigger step of moving to C# and a managed runtime.

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 19:51 UTC (Tue) by jzbiciak (guest, #5246) [Link] (1 responses)

I just took gnome-shell for a test drive (on Fedora 12) and it didn't feel like a Mac at all.

Feeling like a Mac in operation is rather different than looking like a Mac "at first glance." I have to say I agree with Bruce that "Docky" looks like a differently themed version of the dock I see on MacOS X. It doesn't matter if it actually behaves differently. It certainly looks very similar, right down to that proximity-based progressive icon resizing. And that blue-wavey background also looks vaguely familiar

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 19:54 UTC (Tue) by jzbiciak (guest, #5246) [Link]

Not to mention that workspaces screenshot...

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 12:42 UTC (Tue) by pboddie (guest, #50784) [Link] (8 responses)

I think it's unfortunate that people put Mac OS X on some kind of pedestal, especially when the whole dock concept reminds me most of CDE but with extra "bling", when various other user interface concepts have been around for years. I still think we're in the dark ages when applications have you open up a tiny file manager when Acorn RISC OS and Sun OpenLook had drag-saving back in the late 1980s.

Sigh. Don't they look mac-like?

Posted Mar 9, 2010 16:01 UTC (Tue) by nix (subscriber, #2304) [Link] (7 responses)

The problem with drag-saving is it doesn't work very well. So you want to
save a file. You normally work with your app maximized; your file manager
is minimized, entirely obscured by the app, or on a different virtual
desktop altogether. So where do you drag the app to? You have to hold down
the mouse button and simultaneously alt-tab (or similarly
keyboard-navigate) your way to the file manager to drop it in there... and
then you might well find out that it's in the right place.

What *should* happen, IMNSHO, is that the app should pop up a new window
on *your existing file manager*, in the app's current directory. So no
horrible per-app file managers and no mad alt-tab horror.

(This is actually quite close to what Windows already does, only it offers
only one choice of file manager, and like virtually everything in Windows
it's modal and horribly limited.)

Drag-and-drop saving

Posted Mar 10, 2010 11:54 UTC (Wed) by epa (subscriber, #39769) [Link]

A big part of the problem is window managers which force an application's window to the front whenever you click on any part of it. I really can't understand why that is considered the best behaviour. Even nontechnical users can understand the idea of one window being behind another, as in the real world we often see one object partly obscuring another.

Also, it does depend on having what GNOME calls a 'spatial' file manager, where you can have one window open for one directory and a different window for another directory. Then if you are doing some work in a directory, you almost certainly have a file window open for it anyway.

(I used to be strongly in favour of this multiple-window style, and found the lack of it on Windows and other clunky interfaces highly annoying. I assumed the lack of a spatial file manager must be a side-effect of the colossally stupid 'multiple document interface' where each application has one big window inside which you can rearrange other windows, and also a side-effect of the aforementioned window manager problem making it impossible to overlap windows, and other Redmondian blunders. But nowadays, with the popularity of web browsers which display a single page at a time and offer 'back' and 'forward', I am not quite so certain. Perhaps a browser-style file manager might have some value after all.)

Note that you only need to drag-save once, to choose the destination directory; after that you just hit 'save'.

What *should* happen, IMNSHO, is that the app should pop up a new window on *your existing file manager*, in the app's current directory. So no horrible per-app file managers and no mad alt-tab horror.
That's not a bad idea.

Sigh. Don't they look mac-like?

Posted Mar 10, 2010 14:01 UTC (Wed) by pboddie (guest, #50784) [Link] (1 responses)

So you want to save a file. You normally work with your app maximized; your file manager is minimized, entirely obscured by the app, or on a different virtual desktop altogether. So where do you drag the app to? You have to hold down the mouse button and simultaneously alt-tab (or similarly keyboard-navigate) your way to the file manager to drop it in there... and then you might well find out that it's in the right place.

On RISC OS, I used to work a lot more with multiple visible windows, despite the ridiculously small screen area by today's standards. However, I'll concede that saving did usually involve bringing the file manager into view, but since the RISC OS Desktop let you preserve window depth - it wasn't the obsessive "pop everything to the top" behaviour seen almost everywhere today - you could actually work with the file manager on top of an application if that was convenient.

Nowadays, with the various dragging operations on desktops like KDE actually supporting navigation - you drag a file onto an application in the desktop pager applet and it makes that application visible - drag saving becomes more viable again. And another thing about the RISC OS drag-saving was that it wasn't just the file manager that supported saving: you could save into other applications in many situations.

My point was that preconceptions about such features should be reevaluated periodically, especially when related features like drag-loading are supported, rather than everyone deciding that something will forever be "wrong", presumably because their Amiga didn't support it or because the usability hammer, Fitt's Law, can be selectively interpreted to claim that it's a bad thing.

Sigh. Don't they look mac-like?

Posted Mar 14, 2010 12:53 UTC (Sun) by nix (subscriber, #2304) [Link]

you could actually work with the file manager on top of an application if that was convenient.
Yes, I hate click-to-raise as well... but when is it convenient to type with a file manager window on top of your text editor? Certainly with non-widescreens it's really quite annoying. It doesn't seem to me to be something you'd ever do unless you were planning to do a drag-to-save in the future. (In a widescreen world this sort of float-on-top could happen much more, as does window splitting and that sort of thing.)

Sigh. Don't they look mac-like?

Posted Mar 11, 2010 11:52 UTC (Thu) by dgm (subscriber, #49227) [Link] (3 responses)

Completely disagree.

While drag-save may be cool, it's not that intuitive. What's more, I have to reach for the mouse to do it.

Per-app file managers are an improvement over the right thing, that is, ask the user for the file name and save it in the working directory. It's an improvement because people sometimes fail to remember what the working directory was, so they cannot find their documents afterwards. Also it allows one to save a file without tacking the hands off the keyboard.

Sigh. Don't they look mac-like?

Posted Mar 14, 2010 12:55 UTC (Sun) by nix (subscriber, #2304) [Link]

Completely disagree.
But then you agreed with me repeatedly. My tiny brain has melted.

Sigh. Don't they look mac-like?

Posted Mar 15, 2010 12:07 UTC (Mon) by pboddie (guest, #50784) [Link]

Well, you could also have the effect of drag-save through keyboard navigation: that's what the "cut", "copy" and "paste" options that appeared in file managers a few years ago are there to support, although they're arguably poorly named. (If you "cut" some files and never "paste" them, are they deleted? Usually not. Other models of manipulating content, particularly for text, did coexist with the cut-copy-paste model for some time, though.)

But this just extends my general point: there are various paradigms that were abandoned, but the rationale for doing so hasn't been adequately articulated. Although there's a notion of a global clipboard, it doesn't always cover whole files, yet they would be logical participants in such a clipboard system.

Sigh. Don't they look mac-like?

Posted Mar 19, 2010 11:44 UTC (Fri) by epa (subscriber, #39769) [Link]

I would say that most users can't remember what the working directory was. Heck, even I can't often find where files have been saved if I just pressed Save then OK and they went to some random location - and this applies on both Windows and Mac.

Given that users have difficulty remembering which directory a file went two, there are two approaches. One is to simplify and clarify things so that everybody can see where files live on disk and where they're saving to: a spatial finder model and drag-and-drop saving are part of this. The alternative approach is to give up and provide some other way for users to find files, such as the 'journal' used in the OLPC's Sugar interface.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds