GUIs and frontends - opinions, suggestions, experience

Mr. Ego · 2008-04-09 17:32:13

I would like to ask you what do you think of frontends and GUIs - if you prefer them, what kind of frontends do you like (complex, easy or with some other features) and for what purposes do you use frontends and when you prefer console. I think it might be interesting source for ideas when writing frontends.

Personally, I have periods when I prefer GUIs and I have periods when i prefer console. I like frontends that offer complex functionality but their controls and functions are not overloading my eyes, when they are good organized.

Recently I got the feeling that there is a trend in simplifying guis at the cost of their functionality due to tendency ot spread among large number of users. I think there is other way - to make interfaces that learn their users (when they want). That means to provide reasonable amount of information for operations (e.g. one or two lines explaining what selected operation does and how it differs from another). If the GUI is a program to change some application configuration file, it could write out, what it changes in file, when this choice is made.
I think that some today frontends have some little issues that can be irritating, e.g. hiding modal window behind other window or not remembering their size.

Personally I like http://smb4k.berlios.de/ a frontend to smbclient and co. The gui is inobtrusive and helpful.
Example of something that I don't like (altough it is a small thing that does not matter to function) is in K3B when main program window with file selection is visible altough I am burning CD image onto disc and therefore I dont't need to see files, main program window could hide for the thime of image burning and show again when image burning is completed.

And what do you think? Are there some things that you would like to see gui for? If there were more people cooperating would you cooperate on development for some gui?
The purpose of this thread could be to point out things that don't have frontend and find people that would participate in their deveopment. But even if you do not want to develop, put your opinion here, it will be interesting.

faelar · 2008-04-09 21:51:42

May not be a good idea but we can start with a troll : GNOME or KDE ? (if you wonder I use openbox )

As you said, some people prefer to have an interface as simple as possible, when others rather like controling every little thing from the GUI.

Don't know to much about apps, but I read a lot of articles about usability and accessibility of websites. I think some principes applied to both of the two world. You have your own vision of "where this button must be placed", a simple exemple, your "file" menu is alway on the top-left of the window.

I really like the opera's way to let the user do what they want with the interface. Just drag'n drop what you need on the panel, move it where you want. Firefox can do that to I know, but not as well as opera, anyway it is not the subject of the topic.

So my suggestion as a simple user, is to provide a GUI as simple as possible for the beginner, but give him the opportunity to add shorcuts to the most advanced/specifics options if he want to do so.

pelle.k · 2008-04-10 00:03:38

I like frontends that offer complex functionality but their controls and functions are not overloading my eyes, when they are good organized.

Me too.
I like GUIs for the day to day stuff, where i do repetitive tasks like browsing files, playing music, setting vanilla preferences. I have always had the idea that a good application should have a library backend, and a cli part for scripting, and a GUI part for light, everyday usage where lots of data and common parameters can be "preset", and used in the GUI frontend.

Creating a good GUI is hard though. That is probably why there is more quality cli applications than the other way around. A cli application also doesn't (for the most part) have to deal with long chains of events, and present the user with new options in a way that looks natural, and pretty for that matter.

Mr. Ego · 2008-04-10 07:15:07

So my suggestion as a simple user, is to provide a GUI as simple as possible for the beginner, but give him the opportunity to add shorcuts to the most advanced/specifics options if he want to do so.

That is interesting idea that sounds good. It also requires from the user to stop and think - "What am I using the most? What I am not using, at all?" From my experience it is sometimes hard to reveal this (or to realize that i could stop and think about the interface), but when it comes to this and I set it up, it's really amazing and comfortable.

May not be a good idea but we can start with a troll : GNOME or KDE ? (if you wonder I use openbox )

I hope thtis will not be a flame
Currently I am running KdeMod http://kdemod.ath.cx/ a modularized and perhaps optimised version of KDE. I used both KDE and GNOME. In some programs in GNOME I like their simplicity, for example CD image burning with nautilus that is small, simple and provides all the informations user needs (well, perhaps MD5sum checking could be added... hmm, sounds like a place for giving user the oportunity to set if he wants to see the field for MD5sum validation ). In other programs I am missing more complex functionality or settings. Some settings could be also changed only with gconf editor. GConf configuration tree reminds me windows registry. The good thing at GConf tree is that the a lot of keys is commented - it says what the key means and what values it can be set to. The "dark" side of this is that I think it is user unfriendly. I think software should not hide its settings to user, it could manage its settings in a way that advanced settings do not mess with the easy ones.
For example I set Gnome-panel to hide automatically. It hided, but there was a 5 px overlaping from the border of the screen. There was not a way to set the overlap amount in gui. Instead i had to go to Gconf-editor, find configuration of gnome-panel and change corresponding key manually. In other case, I have not found a way how to setup from gui if numlock should be turned on or off when starting GNOME. I had to go to Gconf-editor, too.
Personally I think that it is better to separate program configuration into separate files rather than putting it into one big tree.

In KDE there are a lot of things that can be set from a GUI. I think sometimes it is too much, but for me it is better to be able to configure everything about application in GUI rather than seeking hidden settings somewhere else (I hope this will not be taken as a reason for a flame ). But I found KDE quite bloated with applications and slow. For example there is a number of media players - Noatun, Amarok, Juk (I don't know if this is a part of KDE), Kscd, Kmid. I found that some files played in noatun and other in other program (can't remember hwat it was). I think it would be better to integrate MP3, CD and MIDI players to one audio player (maybe that is Amarok yet?). Menus were then full of applications that i never really used and only distorted my attention.

I used fluxbox and openbox for a long time before I tried those two (GNOME and KDE). What I like about those managers is that they are lightweight and then small and fast. But I find myself being more and more lazy and i wanted to have panel (so I used gnome-panel), automatical volume mounting ( i used that from GNOME), or I wanted a desktop that could be easily configured (right click and so on), so I used that from KDE (I did not use GNOME and KDE things at once, i changed panels for KDE panel etc). My openbox became more and more slower (that means its speed could be compared to GNOME or KDE) and I realized that what I want was a dekstop, that has a lot of features but is fast.

For those reasons my favorite in this time is KdeMod. It has splitted bundles of KDE applications (splitted media players and so on) and it has fast respone considering it has all the features I turned on in minimalistic environments.

What I don't like about the big environments is that a lot of things is done is their way instead of "natural" or "low-level" way. For example KDE has some special paths like "media:/" that non-KDE applications cannot handle. Or when i browse https with Krusader, i can only use KDE programs to manipulate files with this connection. In my opinion making the things at lowest possible level makes those things available to largest scale of othe applications.

Creating a good GUI is hard though. That is probably why there is more quality cli applications than the other way around.

I agree. Writing application that is customizable, remembers all its settings and makes its configuration enjoyable si a hard job.

I have always had the idea that a good application should have a library backend, and a cli part for scripting, and a GUI part for light, everyday usage where lots of data and common parameters can be "preset", and used in the GUI frontend.

Oh yes, I think this too. Library should handle all the operations program is able to do, and cli, and guis only make access to this functionality. It also allows to write more frontends (e.g. Qt and GTK).

Let's add some question: What gui do you think you are missing (for what purpose)?

pauldonnelly · 2008-04-11 00:45:08

I prefer to have a CLI app for things I do all the time (file management, playing music, calculator, and so on), and a GUI for things I don't do frequently enough to want to memorize their workings. And GUI for programs I plan to spend a lot of time in, like my browser and text editor.

blu3ness · 2008-04-11 00:53:10

I think it depends on the environment and targeted audience.

GUIs are great for apps that require a lot of user interaction. CLI is great for automation and scripting. Getting the best of both worlds right now is still pretty tedious and requires a lot of extra work.

As far as linux goes, CLI definitely crosses platform boundaries, which is nice. GTK/QT apps always require additional libraries and adds to system bloat, which is one of the biggest reasons I stayed away from Amorak despite it's reputable features.

In answering your question, I don't think I'm missing any GUI for the stuff that I could possibly want a GUI for, maybe I just havn't looked hard enough

Last edited by blu3ness (2008-04-11 00:54:46)

arooaroo · 2008-04-11 09:51:36

CLI is important: very powerful, especially when CLI apps can be easily controlled via scripts.

The issue for me is that CLI apps generally require a good memory for anything beyond the basic options. Sure I'll do an 'ls' to see what's in a directory, but if I want to find out the size of a folder, I don't know off the top of my head, and so I'll whizz up the GUI explorer and right-click. It's quick.

Pacman is something I use plenty, and I know all my usual commands. It's positively slower to load up a GUI, for me.

The other day, I realised I needed to mount a drive. I always forget what to do here. I tend to do it once when setting up the fstab on a new linux install and that's that. I'd much prefer to have a quick app to help me out there, but it's something of a one off.

Basically, it's key to have CLIs for everyone, not just power users. Especially as each user is different and have different requirements. But GUIs are great for just plain-old-users who want to do some quick operations, like burning CDs or some configuration tweaks without having to search and read loads of man pages. GUIs are often just easier to recognise what you need to do.

11010010110 · 2008-04-11 14:44:16

I like this way

There is everything in the gui

The software does not attempt to learn me, just alwas shows all the features

I can customize the menu and toolbars manually thru the options

If I need an option that I removed from the accessible places I have a way to get to it

I use kde 3.5. The more I use it the more apps look like empty window without any toolbars etc and whatever I need set as key shortcuts or in the right click menu

If i need something I removed I can show the menu (ctrl m) and its there

dav7 · 2008-04-14 13:40:55

NOTE: This post is 20K. You might want to think twice before starting reading it. If you're like "whoa, TL;DR" please actually respond so that I know how many people refuse to read a 20K forum post XD

Well, as someone who thinks about user interfaces every second day I have a lot to say on this matter. A few years ago I got an idea to create a user interface beyond all others. Its first incantations were very primitive, but as I thought about it, it got better, and in the past two years I've come further than Steve Jobs and Bill Gates have in the past 20 years, and surpassed Compiz Fusion.

Of course, with no way to express the visual portions of my mental developments this is all still in my head, but one day, I hope to get my visual concepts onto a computer screen and into the "desktop interface" market, as GPLd software. It'll be interesting, with my not knowing a single bit of math... heh..

For now, however, I can enjoy ranting and raving about the current state graphical interfaces are in - and, here and there, computers in general - and I'll do this today.

Firstly,

In my opinion making the things at lowest possible level makes those things available to largest scale of othe applications.

I agree with this, to an extent.

In my opinion, the concepts and analogies behind user interfaces should be strongly seperated from everything else in certain key areas, such as program configuration, interface customization, the user interface itself, and finally the paradigms around the UI.

I won't be discussing desktops in general here; I'll make a few gestures at Openbox, but I'll be mainly discussing my own user interface thoughts, as well as the "advances" I've made over the months.

I'll start by discussing the current state of user interfaces, as I percieve them.

Program configuration

This is the process of a user taking a program and setting it up to suit their tastes, behaviours, and "little quirks", so that the user feels as much "at home" when using the application as they can. This may be as simple as modifying a menu, or may go as far as recompiling the code. I've done the latter with my windowmanager, Openbox, to remove the code related to setting the mouse pointer shape when my pointer is near the edge of a window, since I dislike this behavior as I use keyboard shortcuts to manage window resizing, and I've also changed the names of a couple of menus to suit the theme I have better.

Sometimes, when a user's mood and/or taste changes, they may find their programs so unfriendly to them they may reconfigure the program at a later date to suit themselves better.

Interface customization

This is similar to configuration, except it relates to the user interface at a higher level. This process involves things such as menu modification, appearance customization and related concepts.

I've configured Openbox by modifying the source code, but customized it by changing the options and settings in rc.xml.

The GUI itself

Visual content ranges in many different ways, although I'd say it's fair to classify this as an example of the worst GUI design around, and this as the best GUI around.

If you're wondering why that 2nd image is a blank picture, that's because there is no "best GUI" or "best theme" in existance. We like what we like individually. What I like may not be what you like, and vice versa. I might REALLY like this while you might not be able to see the content for the purple. I might regard this as a huge waste of graphics card resources while you might consider it the coolest thing in existance (although I can't possibly understand why you could, and you're probably indignant at that fact).

The job of the user interface designer is not to create something which they like - but to instead create something that is "opinion-agnostic", something that contains no visual innuendo, does not steer toward any visual design, and something that all users will like, the last being practically impossible, and the points before it quasi-reachable via the use of desktop environment "standards".

Today's user interfaces follow schemes invented by the two leading UIs that exist today: Mac OS and Windows. I prefer to use the term "Winfailure" for the latter, so I'll call it that from this point forward.

First, we have a "background" which can typically display a pattern or picture, and contains shortcuts to whatever programs we might wish to run at either the right or left of the screen.

Next, "windows" are typically boxes with a bar at the top people typically have registered as "drag this and you'll move the box" which has 2 or 3 buttons over to the left or right of it, and then the contents of the box (window) itself, whatever it may be. On Mac OS, dragging what of the window itself is visible will also move the window, but not many people know this.

A few Linux windowmanagers (such as twm) don't follow this rule (I mean, why should it, it's a UNIX program), and yet other windowmanagers do follow this rule but allow you to change it to suit your own preferences, but these are typically the concepts behind most desktops today. Why? They work... really well. Some WMs even pack extra functionality into the 3 buttons available: middle-clicking the maximize button will probably maximize the window vertically, and right-clicking it will maximize the window horizontally. Since Openbox supports this, I use it semi-frequently and find it a great productivity help.

Like I briefly touched on in my last post, desktop environment standards have attempted to create a visual consistency across applications, and for the most part it's worked, but some Winfailure programs consider whatever theme you're using (be it a default or included theme, or one you've carefully handpicked for yourself and really like) to be worthless and implement their own UI. Some even go so far as to use their own UI layout standard. I actually wrote a skinning engine specifically for a "toy" application back in my Winfailure days, but I (now thankfully) never really finished the app itself, as I now consider "own-skinned" apps to be very bad for visual integration - even Apple acknowledged this, back when they announced that the latest version of Mac OS X would feature consistently themed windows. I'm pretty sure this is because half the Mac OS developers out there had no idea which of the two "styles" to use (there were two styles available to all window types before OS X Leopard) so they probably just picked the one they liked the most.

The paradigms behind the GUI

Paradigims are things we can't see, paradigms are the underlying concepts behind a visual user interface that steer it in a consistent direction so that we don't lose ourselves within it and/or don't find parts of it "out of place", a sure concentration/"continuity"-breaker.

Ever since Apple stole Xerox PARC's idea of the onscreen desktop, everyone's been using the concept of the desktop - because it's a great idea. Icons for things we might use, boxes representing paper, areas of the screen one could click to make small boxes momentarily appear the computer geeks called "menus"... Steve Jobs knew a huge success when he saw one, so he snapped up the idea of the GUI and the desktop paradigm and instantly ran with it. And we still use it today.

...with all that in mind...

I've thought about the 4 points presented above fairly often over the past few years, and I have a complete UI to speak for it - one, unfortunately, I cannot actually show. As companion subjects, I've also thought about immersive computing, hardware design, and the like and also have a few hardware-oriented plans to go with my UI, but I'll just discuss a few points from my UI below for now.

Program configuration

Instead of having a thousand and one configuration "types", there is one central configuration system, which uses a modular system with plugins to dictate the way the plugin system itself would work, and saves actual configuration files as XML. Programs use a unified library to access, change and create these configuration options, and the system updates itself and other programs in real-time according to the changes... or you can ignore all that and write and read the XML files yourself, and use the wonder called Inotify to alert the system of changes automatically.

For those who like the commandline more than the GUI and are configuration file lovers (like myself, to be honest), a variety of pseudo-configuration-file formats (pseudo because each "format" would be being translated into XML as options were changed and saved) would be available, such as he .ini format, the Irssi IRC client's format, XML itself (abstracted in a few different ways), C arrays, etc. One could even create plugins that emulate subsets of programming languages so that options could be stored as "PHP arrays" or "Python hashes" or "BASIC strings", for instance.

For those who prefer GUIs, a full XML-to-GUI "rendering" system would take various XML options and convert them to frames with buttons, textboxes, dropdown lists, and the like inside.

Both of the above would be able to be rendered in a number of different formats; for example, you might have tabs and menus seperating the areas of customization available in what programs you have installed, or you might have one large flat (2D) pane with every option on it rendered in 3D space that you can zoom into and out of much like the Compiz desktop zoom plugin. This would work for both the graphical and text versions, the latter being rendered as a gigantic terminal emulator window (with very intelligent memory management).

For the text version, an additional "rendering" mode would be available that simulated the simplicity and secretive discoverability of the CLI, allowing usage of common UNIX commands to browse folders and edit files (using nano, vi, emacs, etc)

Lastly, I was configuring my kernel one day and thought "hey... a menuconfig-like interface for my UI's configuration thingy would be a cool idea!" so this would be one of the additionally available options - as well as having xconfig and gconfig available, and I'd hope to have an actual pseudo-.config file fully editable, complete with Kconfig files in all the correct pseudo-places.

Interface customization

With configuration out of the way, customization is another issue - and I don't just mean adding or removing the odd menu or toolbar item or changing a shortcut, I mean true customization: changing button labels, adding buttons to toolbars that don't natively have a handling system for adding/removing toolbar items, and so on.

To manage the way programs feel - not look, that's handled by the theme you have loaded - you need a sane system similar in behavior to the configuration system. So, in my UI a "central" configuration system exists, and once "entered" all other windows and dialogs disappear from view so you can focus on editing the dialog you have visible. You are provided with a user interface not unlike that of a dialog editor, and you can create toolbars, controls and so on and also edit the style, captions, functionality etc of existing controls.

Like the configuration system, programs use a unified system of loading and managing user interface elements visually similar to the way GTK's Glade system functions, and programmatically similar to Kdevelop in that "elements" are "bound" to program code via strings and so on.

Because elements are bound to strings, a user could modify a program's user interface to look nothing like the way it used to yet function exactly the same. Winfailure shows a possible attempt at something like this in its usage of dialog resources; these are compiled into programs in an easily readable way, permitting viewing and even resource modification and binary recompilation. 3 years ago when I was 14 (I'm 17 as of now - 2008) I used Resource Hacker to modify the resources in the Winfailure Sound Recorder app to look entirely different but function exactly the same.

Here's the original, and here's my replacement layout.

I think mine is a little nicer - and it shows EVERYTHING you can do, rather than hiding it all away in menus. I'm one for "non-discoverability" when it comes to graphical applications; I was back then and still I am now - I want my apps to show me every possible option available, not tuck 85% of the application away in menus, forcing me to manually USE ENERGY discovering what I can do in any given application. Sure, the Sound Recorder window *is* smaller, but does that make it more usable? I developed "LargePlayer" on an 800x600 screen, and while it did take up a lot of screen real estate, it was still usable. Given the option (and code sanity - the Soundrec codebase cannot edit anything other than WAVs!) would you pick the former or the latter UI for a "minimalistic" sound editor?

The GUI itself

In my major thinkings, I've developed a clean, consise, concurrent and consistent *ahem* user interface layout that doesn't encompass the "desktop paradigm" as much as Xerox PARC did, all those years ago.

It actually does look good, while easing the user out of what they've accustomed themselves to over the past 20 years.

A couple of user interface element examples:

Windows are rendered as frosted "ice" glass panes with "tubes" at the bottom of said glass panes. The tubes themselves are rendered as matt-finish, slightly-frosted glassy "beakers" (rotated horizontally) and they have "slots" in the middle for the windows that reside within these tubes. The tube is a visual representation of the "persistence" of the window; the glass itself which holds the window's content can be made invisible, but the tube itself is a visible indication of the program's core running. Once the tube is gone, you know the application is closed. Therefore, programs don't have (explicit) control over the tube; they only have control over whether the tube is displaying the glass window itself. A tube appears when any graphical program is running. Of course, you can prevent a specific set of programs from displaying tubes, and the "do not display tube" blacklist would be stored in the system and would be owned by root, so you'll immediately know if any random program has executed (provided it's not on the blacklist). This is to promote accountability.

The tubes are fully "available" to programmatical and visual modification (the latter being via my customization system), and could also be used as a sort of per-application notification/control area... in a text editor, for example, it could show a red disk icon when the currently loaded file (and/or active tab in the case of a tabbed editor) was not saved, and a green icon when the file was saved. One could even go 'all out' and use the tube as the area back/next buttons could be put on in the case of a web browser.

The "panes" would also appear to gently "hover in space"; when moved, they have a sort of "rebound" - sort of like the existing Compiz Fusion "wobbly windows" algorithm, but slowed down for a more graceful appearance. Windows can also possibly flutter as the mouse goes past, simulating a virtual breeze greated by your mouse's pointer.

The paradigms behind the GUI

The concept of a desktop was used 20 years ago because it was all that was managable with the hardware available. We can do better than that now, and my user interface encompasses that as one of its fundamental goals.

A paridigim example:

Rather than stick to plain "desk"top with menus, buttons and similar controls, my UI takes these to the next level with a truly 3D desktop with "levels" - a Z-axis upon which windows can "nest" within. Scripting and/or filtering can then be applied to these "levels" to alter any windows within a given level's appearance or behavior. A key combination could be used to place a given window in a given "level".

The concept of "sections" or "seclusions" on the screen is exactly the above, but instead of dividing the desktop up into "levels", this would instead be a custom movable "frame" with nominally no titlebar (although one could be added). When moved over an area of the screen, any applications (or part of an application) within that area would take on the filters or scripts selected (as described by the previous paragraph). This is probably going to require some careful thinking before implementing so two windowmanagers can be running at the same time, and only a portion be visible. For a more complex example, one could configure WINE to use the Windows 95 interface for all windows, then a Seclusion could set WINE to use the Windows 3.1 interface. Moving and sizing said Seclusion to scale one half of the screen would yield very amusing results in this example. Note that within a "section" the mouse can be used as normal; a sort of "click-through" and "type-through" would be implemented. To return control to the frame of this "section" so it can be moved or sized, perhaps a keyboard shortcut could be pressed, or a button clicked.

One paradigm I like very much is the concept of holographic projection: given today's display technology, onscreen holographics would be an easy to simulate concept indicating a transient operation, such as, for example, a form development system displaying a test dialog.

...having said all THAT...

There is no best GUI, and no program with truly limitless configurability, but in my opinion, if the developer imposes programmatical limitation in a framework at points beyond which your everyday geek is going to visit, your average user from Marketing is never going to find the end of the configurability "tube", and maybe the power users will like it too.

But there are going to definately be users that will see holes in my analysis, and I'm welcome to input on all this - in fact, this is the first time I've actually openly discussed my ideas, and I hope you'll be able to give me constructive criticism on it.

If you want to get in touch and possibly help me create a few of these effects, feel free to contact me.

-dav7

PS. Compiz Fusion is pretty good in some areas, but I don't have a "proper" graphics card so Compiz is horrendously slow for me.

Last edited by dav7 (2008-04-14 14:31:49)

Redroar · 2008-04-14 20:43:06

Whew, quite a read.

First, on several of your points I must agree with you. In particular that no two users want the exact same thing, and that a WM/DE interface should be easily modified. I have to say, though, while it all seems perfectly clear to you, I don't think your idea comes through in words. It would be fantastic if you could make a mockup in GIMP to show a sample screenshot.

Personally, I use KDEmod, for 3 reasons. 1) I like KDE apps, and KDEmod lets me choose the ones I want. 2) I prefer controlling the GUI with a GUI. Text config files for system options are excellent, but I just can't quite deal with it for GUI options. Some people can edit a text config file (gtkrc, for example) and know exactly what they're getting. I'm not one of them. And 3) I prefer programming in Qt than GTK.

But I would really like to see a mockup of what you had in mind. Perhaps it follows with my 2nd reason for using KDE, but I just can't quite picture what you are describing.

pelle.k · 2008-04-14 21:51:36

dav7,
I love your idea of using XML (or something of that sort) to create a bridge between CLI/GUI applications, and their functionality. I have often thought about that myself.
Also, having XML files, could with the use of DTDs and stylesheets completely replace plain text configs, and all the downsides that they bring. Think about it. Error checking and value/string suggestions right in the XML editor, instead of that being done in every application (at runtime, or it may also just fail silently) installed on the system individually. That would be freakin great!

finferflu · 2008-04-14 22:04:32

TL;DR
That's actually the longest forum post I've ever seen in my life, but it sounds very interesting, I will surely read it when I have the time and am more awake

dav7 · 2008-04-15 06:44:45

Redroar: I can see what you mean, and...

dav7 wrote:

For those who prefer GUIs, a full XML-to-GUI "rendering" system would take various XML options and convert them to frames with buttons, textboxes, dropdown lists, and the like inside.

...was thought up to take care of just that.

Also, regarding...

Redroar wrote:

It would be fantastic if you could make a mockup in GIMP to show a sample screenshot.

...I can't for a rather ironic reason: I find the user interface unusable because it doesn't suit my personal taste, and doesn't "flow" for me (and probably a great many other users). Plus, I'm a visual person, but not in the typical sense: I'm terrible with "single frames"; I'm an animation guy (without the animation tools, heh). So The GIMP wouldn't work out anyway, I'd need Blender or something. Which has (IMHO) an even more "unlearnable" GUI, and I don't have the video hardware to render stuff anyway (my PC chokes on just watching video).

pelle.k: I also love the idea of using XML for system configuration... in fact, I can see that the future is XML. The "mad scientists" who invented HTML didn't think their format would gain the popularity it has, but like the desktop paradigm, it just... works, so people love it. Since you like XML, your ideas could be added to my

dav7 wrote:

... XML itself (abstracted in a few different ways) ...

section of the configuration system.

Basically, my config system would be modular so people could configure the way they wanted to configure their systems. ...Right. While on paper it might sound stupid, having the way you configure your system configured itself "to the hilt" would make you a more productive person.
Because which is fastest: spending anywhere from an hour to a week tweaking a configuration tool to suit your personality, or spending 15 minutes with it every time you want to change something, trying to figure out how it works? I'm a "spend a long time doing something once, so it 'just works' afterward." guy. Kinda like taking the time and making the effort to make a robot to wash the dishes, except somewhat more feasible.

finferflu: Ah

Last edited by dav7 (2008-04-16 03:58:18)

n8schicht · 2008-04-15 14:31:33

Mr. Ego wrote:

Example of something that I don't like (altough it is a small thing that does not matter to function) is in K3B when main program window with file selection is visible altough I am burning CD image onto disc and therefore I dont't need to see files, main program window could hide for the thime of image burning and show again when image burning is completed.

Tadaaaaaa:

Sorry, I could not resist answering to this one. The K3B interface is actually a good example of giving a lot of freedom to the user.

Mr. Ego · 2008-04-16 08:32:40

Sorry, I could not resist answering to this one

That's good. Thanks! I did not know about this option.

...a variety of pseudo-configuration-file formats (pseudo because each "format" would be being translated into XML as options were changed and saved) would be available...

That is interesting idea. Have you thinked about how it would be done. e.g. if there would be place to put this custon configuration file, program will spot it, import into XML and delete or would it export it complete configuration to custom configuration format and then import it back? Or any other way?
Personally, I think I might appreciate YAML http://www.yaml.org/start.html. It seems to me more human readable than XML and it is still machine parseable.

Also, having XML files, could with the use of DTDs and stylesheets completely replace plain text configs, and all the downsides that they bring.

That is damn cool idea. I don't know XML so much, but is there a way that XML modifications could be made without the need of an external program (I mean only in XML browser), or would be there a need for some piece of code to allow modification of that XML?
I think in this time it would be even possible to render a XUL interface http://www.mozilla.org/projects/xul/ with an XSLT stylesheet. I think (but I am not sure) XUL interface files could be read and displayed like dialogs by Mozilla. But it would bind it to a web broswer and GTK interface.

dav7 · 2008-04-16 11:26:15

Hm, YAML seems very interesting. That could also be added to my configuration system as one of the plugins.

And yes, the Firefox engine is based upon a XUL framework - in fact, XUL was written so that developing Netscape's UI would be easier, afaik. So using XUL and/or XML+XSLT would be an interesting solution, although one I'll admit I wouldn't prefer, because to be honest I don't see Web applications as the future, and won't until I see the Web more closely integrated with the desktop. I have a few ideas and plans for that too, but I don't think you guys would appreciate another essay... ;P

-dav7

pauldonnelly · 2008-04-16 18:32:43

dav7 wrote:

NOTE: This post is 20K. You might want to think twice before starting reading it. If you're like "whoa, TL;DR" please actually respond so that I know how many people refuse to read a 20K forum post XD

Okay then: tl;dr. I'd read a long post, but it seems like there's a lot of fluff in here. Any way you could create a condensed version describing just the UI (without talk about motivation or how it will be rendered) in six sentences or so?

inf · 2008-04-17 04:07:25

I mostly don't use GUIs and I could maybe say that I hate them. Not all GUIs are bad, but mostly they're created to maximize the easy-way-to-configure, and this is usually the reason why I hate GUIs.

That's prolly the reason why I hate/dislike distros like Ubuntu. I think Ubuntu is maybe one of the extreme examples of how things are done "wrong". Of course you have to keep in mind that Ubuntu is a "newbie-friendly" distribution and it always will be, because that's the goal they try to archive.

I myself love distros like Arch/Gentoo and FreeBSD, which let the user in control.

dav7 · 2008-04-17 09:40:58

pauldonnelly: Erm... we have a small problem. My post is only about motivation and the only other thing it discusses is how it's rendered. Honestly. And about the fluff: what you consider fluff may not be the same as what I consider fluff!

inf: I agree with that method of thinking, and am very much that way myself. It won't be long before I consider using a tiling wm again. I might restart with such a wm, go "GAH" and not touch the concept for another month, but it's safe to say I'll be giving the concept a go. Oh, and Ubuntu is nice... but, well, yeah. Not much more. It tries to be too "nice".

Now, to reinvent the internet using just text...

-dav7

faelar · 2008-04-17 15:40:11

Just want to add a new point, as anyone tried a radial menu ?
Wikipedia will explain this better than I will
http://en.wikipedia.org/wiki/Pie_menu

dav7 · 2008-04-19 06:43:23

I think it's been hyped/rumoured Winfailure 7 will have a pie/hexagonal menu, although I'm not sure.

Btw, after spending a bit of time clicking about I found this bit of WOWness that is entirely off-topic:

Wikipedia wrote:

PowerAnimator was used to create the water creature in the 1989 film The Abyss, as well as the T-1000 character in Terminator 2: Judgment Day, at a cost of $460,000 per minute.

That was from http://en.wikipedia.org/wiki/Poweranimator (in section 5), which is linked to in http://en.wikipedia.org/wiki/Pie_menu.

It had me shocked for a little while, so I thought I'd share it with you too.

-dav7

Arch Linux

#1 2008-04-09 17:32:13

GUIs and frontends - opinions, suggestions, experience

#2 2008-04-09 21:51:42

Re: GUIs and frontends - opinions, suggestions, experience

#3 2008-04-10 00:03:38

Re: GUIs and frontends - opinions, suggestions, experience

#4 2008-04-10 07:15:07

Re: GUIs and frontends - opinions, suggestions, experience

#5 2008-04-11 00:45:08

Re: GUIs and frontends - opinions, suggestions, experience

#6 2008-04-11 00:53:10

Re: GUIs and frontends - opinions, suggestions, experience

#7 2008-04-11 09:51:36

Re: GUIs and frontends - opinions, suggestions, experience

#8 2008-04-11 14:44:16

Re: GUIs and frontends - opinions, suggestions, experience

#9 2008-04-14 13:40:55

Re: GUIs and frontends - opinions, suggestions, experience

#10 2008-04-14 20:43:06

Re: GUIs and frontends - opinions, suggestions, experience

#11 2008-04-14 21:51:36

Re: GUIs and frontends - opinions, suggestions, experience

#12 2008-04-14 22:04:32

Re: GUIs and frontends - opinions, suggestions, experience

#13 2008-04-15 06:44:45

Re: GUIs and frontends - opinions, suggestions, experience

#14 2008-04-15 14:31:33

Re: GUIs and frontends - opinions, suggestions, experience

#15 2008-04-16 08:32:40

Re: GUIs and frontends - opinions, suggestions, experience

#16 2008-04-16 11:26:15

Re: GUIs and frontends - opinions, suggestions, experience

#17 2008-04-16 18:32:43

Re: GUIs and frontends - opinions, suggestions, experience

#18 2008-04-17 04:07:25

Re: GUIs and frontends - opinions, suggestions, experience

#19 2008-04-17 09:40:58

Re: GUIs and frontends - opinions, suggestions, experience

#20 2008-04-17 15:40:11

Re: GUIs and frontends - opinions, suggestions, experience

#21 2008-04-19 06:43:23

Re: GUIs and frontends - opinions, suggestions, experience

Board footer